New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recursive dependency handling for charts. #2247
Comments
Marking this as a proposal for discussion. Once it has been discussed and scoped out, we can tag it as a feature. |
Thanks @thomastaylor312 . Waiting for others concerns on the design. |
I'm in favor of adding a |
Do we allow the |
I don't think there is a need to build in a specific |
Yes, I am going to submit PR for this. |
Yeah, I think that is the best idea |
What is the plan for if two subscharts have different dependency versions? EG
|
I've filed a relevant issue: #2759 |
Issues go stale after 90d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
Hi, any update on this? |
@devlounge See the status in the PR here. We are stuck at the point where some tests are needed. Would you mind to test the PR branch with your charts? |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle rotten |
/lifecycle frozen |
Any status regarding the writing of the HIP for this issue? Would be great to have this enabled by default since atm nested chart dependencies will fail silently/not produce anything. |
This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs. |
bump |
/remove-lifecycle stale |
Another script to do a recursive #!/bin/sh
#
# helm-dep-build-recursive
#
# Recursive version of `helm dep build`.
#
# Will hopefully become obsolete after: https://github.com/helm/helm/issues/2247
refreshdone=0
subcharts=$(ls `find . -name charts | sed 's/$/\/*\/Chart.yaml/'` 2>/dev/null | sed 's/\/Chart\.yaml$//')
for chart in . $subcharts; do
if helm dep list $chart | grep -v '\(^\|WARNING: no dependencies.*\|STATUS\|ok\|unpacked\)\s*$' >/dev/null; then
if [ "$refreshdone" = 0 ]; then
helm dep build $chart
refreshdone=1
else
helm dep build --skip-refresh $chart
fi
fi
done |
Getting close to 6 years. Any updates on this? |
Okay, I'm giving a shot at this. 💪 |
Hi all, I have a working PR: #11766 The commands I'm purposing look like:
If someone could test with my branch; you only need to run a If you all could 👍 the PR, it would help a lot to get some traction on this. Thanks! |
Any update on this issue. I prefer to have native support from helm for this feature rather than apply workaround |
@Migara-Pramod I'm still waiting for an official review of this PR =/ |
I'm also hoping for this feature to be added |
Almost 7 years waiting the feature! any news ? |
+1, we have nested helm charts and resolving them each time is a major headache for us |
Came here looking for a solution to recursive dependencies too. Seems like a reasonable thing to do with helm charts and not a very hard thing to support fully. |
+1, I am also looking for this solution. |
+1 |
1 similar comment
+1 |
Is this feature ever going to come? 🤔 |
+1 |
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 thecharts/
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 fakinghelm dependency build
steps.Solution:
Would be good to have a
--recursive
flag to thedependency build
command inhelm
. 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 😄.The ultimate solution would be to have this implicit chart procurement option in case of
helm install
.Problem statement in slack archive.
The text was updated successfully, but these errors were encountered: