Open mandelsoft opened 1 month ago
These dependencies are usually evaluated by helm dep build
and the respective charts will be placed in the charts/
subdirectory. Illustrative example using a fresh checkout of https://github.com/sapcc/helm-charts/tree/master/openstack/content-repo:
$ cd openstack/content-repo
$ ls charts
ls: cannot access 'charts': No such file or directory
$ helm lint . --values ci/test-values.yaml
==> Linting .
[INFO] Chart.yaml: icon is recommended
[WARNING] /x/src/github.com/sapcc/helm-charts/openstack/content-repo: chart directory is missing these dependencies: linkerd-support,owner-info
1 chart(s) linted, 0 chart(s) failed
$ helm dep build
Saving 2 charts
Downloading linkerd-support from repo oci://keppel.eu-de-1.cloud.sap/ccloud-helm
Pulled: keppel.eu-de-1.cloud.sap/ccloud-helm/linkerd-support:1.0.0
Digest: sha256:2f9ecf9ab62c1f73c15bdbd0dc0316860dd6d0c551d6b6d5d94568f2e2bd57a8
Downloading owner-info from repo oci://keppel.eu-de-1.cloud.sap/ccloud-helm
Pulled: keppel.eu-de-1.cloud.sap/ccloud-helm/owner-info:1.0.0
Digest: sha256:343ea4e433a0482cffd334f5a85d2ca9abc7ece8fd94169c4a42e7b3365ee91a
Deleting outdated charts
$ ls charts
linkerd-support-1.0.0.tgz owner-info-1.0.0.tgz
$ helm lint . --values ci/test-values.yaml
==> Linting .
[INFO] Chart.yaml: icon is recommended
1 chart(s) linted, 0 chart(s) failed
So there is an option for a "cheap" solution wherein ocm add resources
just fails when a Helm chart is added, but some of its dependencies are missing and cannot be added. The error message should then warn the user to run helm dep build
first.
I double-checked what I only assumed in the previous comment: Running helm dep build
before ocm add resources
works as intended. The subcharts end up bundled together with their parent chart:
$ curl -L -s https://<hostname-redacted>/v2/d063094-ocm-test/cloud.sap/plusone/content-repo-with-subcharts/content-repo/blobs/sha256:5d5aa1135406e130207f32f32aeee9eaefa15620750a699b59635ee5d4b17a38 | gunzip -c | tar t
content-repo/Chart.yaml
content-repo/Chart.lock
content-repo/values.yaml
content-repo/templates/_utils.tpl
content-repo/templates/configmap-bin.yaml
content-repo/templates/configmap-statsd.yaml
content-repo/templates/configmap.yaml
content-repo/templates/cronjob.yaml
content-repo/templates/deployment-check.yaml
content-repo/templates/deployment-statsd.yaml
content-repo/templates/prometheus-alerts.yaml
content-repo/templates/secret-certs.yaml
content-repo/templates/secret.yaml
content-repo/templates/service.yaml
content-repo/README.md
content-repo/alerts/content-repo.alerts
content-repo/bin/check-rhn
content-repo/ci/test-values.yaml
content-repo/charts/linkerd-support/Chart.yaml
content-repo/charts/linkerd-support/values.yaml
content-repo/charts/linkerd-support/templates/namespace-annotation.yaml
content-repo/charts/linkerd-support/README.md
content-repo/charts/owner-info/Chart.yaml
content-repo/charts/owner-info/values.yaml
content-repo/charts/owner-info/templates/configmap.yaml
content-repo/charts/owner-info/README.md
content-repo/charts/owner-info/ci/test-values.yaml
The last nine files (everything below content-repo/charts/
) belongs to subcharts that ocm add resources
specifically unpacked from their .tgz
form. So this is only about doing the helm dep build
part in OCM or rejecting charts where helm dep build
has not been run (i.e. when traversing the dependencies
relations of the chart and its subcharts, any of the referenced charts is missing in the filesystem).
What would you like to be added:
So far, the helm input type allows to package a helm chart from the filesystem or any other source as local blob resource.
To use sub charts, those sub chards must already charts described a s local sub charts be the main helm chart.
Required is the possibility to additionally describe charts, which should be packaged together with the main chart as local sub charts.
This could be described in several ways:
the dependency information in the
Chart.yaml
contains the location f the sub charts. They are just internalized by the input.To be able to keep references, this would require an optional flag in the input spec to enable the internalization behaviour. For the internalized charts the dependency entry has to be adapted to refer to the local representation.
The input spec makes it possible to describe a dependency list for the charts, which should be internalized. The dependency field of the
Chart.yaml
has be extended by the specified sub chart names.In both cases the effective chart has to be prepared on a temporary filesystem by copying the main one, adding the additional sub charts to the filesystem content and modifying the
Chart.yaml
.Why is this needed:
Requested by @majewsky