Dependencies of local dependency are not packaged.

[clement-buchart]

Hello,

I'm having an issue with a HelmChart which is targeting a folder in a GitRepository. The chart root located in this folder has a dependency on another local chart, component, specified as such :

dependencies:
- name: component
  version: 0.1.0
  repository: file://../component
  alias: mycomponent

This works fine and if I download the package tgz from the source-controller, it contains the component chart in the charts subfolder.

But, this component chart also has a dependency on postgresql, specified as such :

dependencies:
- name: postgresql
  condition: postgresql.deploy
  version: "9.8.3"
  repository: https://charts.bitnami.com/bitnami

And this is not included in the tgz, which cause my deployment to fail.

For what it's worth, calling helm package on root does package recursively : root/charts/component/charts/postgresql/Chart.yaml, which means a traditional helm install works.

I looked at the code, it seems it is because the dependency resolution is not recursive and https://github.com/fluxcd/source-controller/blob/aed11a171f527f16d121597b3c40cd4eae84332c/internal/helm/dependency_manager.go#L80 does not resolve dependency before loading the subchart.

Is there something I am missing ?

Thank you.

[relu]

Hello @clement-buchart, thanks for reporting this issue.

I've looked into this and it doesn't look like the helm cli handles dependencies recursively either. For my test case, I created three charts with recursive dependencies as follows:

# recursive-one/Chart.yaml
dependencies:
  - name: recursive-two
    version: "0.1.0"
    repository: "file://../recursive-two"

# recursive-two/Chart.yaml
dependencies:
  - name: recursive-three
    version: "0.1.0"
    repository: "file://../recursive-three"

# recursive-three/Chart.yaml
dependencies:
  - name: grafana
    version: ">=5.7.0"
    repository: "https://grafana.github.io/helm-charts"

The only way to get all the dependencies packaged together recursively via helm package is to priorly run helm dep build . in each of the chart directories.

For reference, this is the helm specific implementation. As you can also probably tell, there is no recursion build and rather dependencies are only resolved at the first level. Here's a relevant issue from 2017 regarding helm recursive dependency management: https://github.com/helm/helm/issues/2247 (it seems it never materialized).

I think the use case you presented here makes sense and would be tempted to investigate further for a potential solution.

If you're looking for a temporary workaround, you need to ensure that local dependency charts (e.g. the component chart in your case) have their charts/ directories populated (helm dep build .) and committed to git.

[clement-buchart]

Hello,

Yes, sorry for the misunderstanding : Indeed it works via the helm CLI only if helm dep update is run prior. And I can also confirm that committing the dependency to git does work, that is the workaround I went with.

I'm glad you'll consider investigating further anyway and will follow this issue. If I can help with the implementation or testing of a solution, I'll be glad to.

[Legion2]

I also ran into this issue. I use three local helm charts where the first depend transitively on the last chart. Only the first two are deploy in the cluster, the manifests of chart which is only transitively referenced is not deployed to the cluster.

Are there any plans to fix or workaround the helm limitation, which does not require me to commit packaged charts into my git repository?

An alternative would be to use a dedicated helm repository instead of a git repository for helm charts. But this would add additional complexity and CI pipeline effort to implement the release process.

[kingdonb]

(Subscribing to this issue).

I am interested conceptually in solutions which can help test packaged dependencies together without requiring a release first. I am not sure whether this is possible now, historically I have just used a beta chart repo where prerelease charts can go, since helm dep update is in the build, but this is feeling quite extra and seems cumbersome.

An effective pipeline for streamlining helm chart releases and easy validation/testing of prereleases is something I would consider as highly desirable as a use case example for Flux.