Recursive dependency handling for charts.
### Use case: Complex applications may have nested dependencies between the different charts. As the dependencies are visible by recursively scanning the charts, it can be naturally desired to assemble top-level charts with single ```helm``` operation. ### Problem: Currently ```helm dependency build``` handles only first-level dependencies. These first level dependencies are put into the ```charts/``` folder in tgz format and treated as complete (assuming second level dependencies built in the first level deps tgz). ### Workaround: Currently user has to create tool which either knows the dependencies in-built or able to scan ```requirements.yaml``` while calling or faking ```helm dependency build``` steps. ### Solution: Would be good to have a ```--recursive``` flag to the ```dependency build``` command in ```helm```. This would scan the dependencies recursively and fixing any missing charts immediately. This would also store the dependencies under ```/charts``` in an untarred manner in order to avoid inception :smile:. The ultimate solution would be to have this implicit chart procurement option in case of ```helm install```. [Problem statement in slack archive.](https://kubernetes.slack.com/conversation/C0NH30761/p1491579986296921)
Posted by libesz on Apr 10, 2017, 1:47 PM
Tags
Related issues
- Some other ones to add on from my fresh install: Start menu search will search the Microsoft Store for apps they want you to install, som...
- New Release?
- 【Not An Issue But Tutorial】A complete tutorial of pre-processing steps
- Meta issue: plugin system
- Accept `Json` field paths when trying to order by `Json` field
- proposal: cmd/go: allow versioned `go build` commands
Raise real-world problems, find people facing the same issue, and discuss solutions.4,500 issues0 comments
onboarding (E-commerce)
Some other ones to add on from my fresh install: Start menu search will search the Microsoft Store for apps they want you to install, som...
New Release?
【Not An Issue But Tutorial】A complete tutorial of pre-processing steps
Meta issue: plugin system
Accept `Json` field paths when trying to order by `Json` field
proposal: cmd/go: allow versioned `go build` commands
[Proposal] New tutorial for "How to install PCL for windows x64 Visual Studio 2019"
index-url extra-index-url install priority order
Recursive dependency handling for charts.
### Use case: Complex applications may have nested dependencies between the different charts. As the dependencies are visible by recursively scanning the charts, it can be naturally desired to assemble top-level charts with single ```helm``` operation. ### Problem: Currently ```helm dependency build``` handles only first-level dependencies. These first level dependencies are put into the ```charts/``` folder in tgz format and treated as complete (assuming second level dependencies built in the first level deps tgz). ### Workaround: Currently user has to create tool which either knows the dependencies in-built or able to scan ```requirements.yaml``` while calling or faking ```helm dependency build``` steps. ### Solution: Would be good to have a ```--recursive``` flag to the ```dependency build``` command in ```helm```. This would scan the dependencies recursively and fixing any missing charts immediately. This would also store the dependencies under ```/charts``` in an untarred manner in order to avoid inception :smile:. The ultimate solution would be to have this implicit chart procurement option in case of ```helm install```. [Problem statement in slack archive.](https://kubernetes.slack.com/conversation/C0NH30761/p1491579986296921)
Comments (0)
No comments yet. Start the discussion.