5

The use case is as follows:

overall-concern/
  charts/
    cloudformation-chart/
    kubernetes-chart/
    shared-library/

Both the Cloudformation and Kubernetes charts rely on the shared library. If I specify it as a dependency in those charts, however, I need to do helm dependency update and it will be copied into those charts' charts/ subdirectory and a Chart.lock file will be generated. That seems unnecessary.

On the other hand, if I symlink the chart:

overall-concern/
  cloudformation-chart/
    charts/
      shared-library -> ../../shared-library

It works, but I receive a warning when running helm template that there are symlinks in the path, leading me to think that this is not intended or is otherwise deprecated:

walk.go:74: found symbolic link in path: ... (paths elided) ...

Is there a blessed solution that will let me use a local chart without treating it as a formal "dependency" in Helm 3?

asthasr
  • 9,125
  • 1
  • 29
  • 43
  • 2
    I've found [this commit](https://github.com/helm/helm/commit/5a7d4f1f748afcbe9c714c1ce35cef7395a157f8#diff-5bd89f2e733a8bb8d60a9cb4947cf0f0R74) which seems to just add info when loading irregular files, so you can use symlinks as you already do and all should be fine – Matt Nov 19 '19 at 13:13
  • Thanks, @HelloWorld, good catch. I've opened [an issue](https://github.com/helm/helm/issues/7019) against the Helm repository. Hopefully there will be some clarification. – asthasr Nov 19 '19 at 13:51
  • 2
    I'm with you. Symlinks are better in a monolith chart repo. Here is how I eat that warning `helm upgrade ... 2> >(grep -v 'found symbolic link' >&2)` per https://stackoverflow.com/a/52575213/207353 – Chris Beck Nov 18 '21 at 21:11

0 Answers0