helm
Feature: add extra flags to skip helm dependencies download
THIS IS A FEATURE REQUEST:
Actually running ct lint on limited connectivity work envs (air gap / train / plain / slow connectivity) give a limited experience, because ct lint is doing a helm depency build even if the awaited tgz are already present.
This also can in some cases lead to unwanted changes to be added to git HEAD (tgz modifications with same versions but different rights or just corrupted during download)
I would suggest adding a flag (and such option in ct.yaml) to allow skipping it.
I guess there are 2 possible ways to implement :
- skip the helm dependency build if tgz are present, but we can't guarantee they are fresh enough
- skip the whole step, relying on the user to do dependency build before running ct
what do you think ?
What I think is that chart-testing developers are generally AWOL 99% of the time.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
@Ornias1993 Please be more kind and control your tone please. If you want to help, please help triage issues and review PRs and add fixes and features.
@Ornias1993 Please be more kind and control your tone please. If you want to help, please help triage issues and review PRs and add fixes and features.
If only triage, review etc got any attention from Helm maintainers. Which, mater of factly isn't the case.
I also already filed a formal complaint towards the CNCF about the lack of activity of the maintainers of Helm, with the ever increasing load of issues and PR's that don't get any attention at-all.
I think the fact you responded on my tone, with the backlog of issues/PRs needing your attention growing, made my case for me.
@Ornias1993
Expressing differing opinions, viewpoints, and experiences is welcome. Making trolling, insulting or derogatory comments is not.
This Helm subproject follows the CNCF Code. Please read this in full. Here are a few of the examples of behavior that contributes to a positive environment:
- Giving and gracefully accepting constructive feedback
- Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
To address your actual issue - as @cpanato said - if you feel the backlog of issues and PRs for this free software is too long, consider helping to reproduce, test, and review them. I acknowledge we need more help with this from community members than we currently have. If you decide to try helping, let me know and I will personally help guide you through the process.
@fredleger apologies for the delay, I will try to prioritize this work and added that to my backlog for my next cycle
@Ornias1993
You for taking responsibility for your mistakes in the mater.
Sadly I wont be able to contribute as al my development time goes into my own project.
Including needing to write custom code for processing helm charts en-masse (900 of them), as Helm tooling has significant performance issues.
Basically I dont have the time left to contribute back to helm, because I already need to spend devtime compensating for helm issues. So quite a catch 22.
@fredleger Have you tried to test and benchmark this process with charts and dependent charts all stored in OCI? This does not address the feature request for Helm HTTP repos, but it may solve your issue since OCI registries do not work with a single index file like HTTP Helm repos do.
@Ornias1993 this may help your scaling issues too:
Including needing to write custom code for processing helm charts en-masse (900 of them), as Helm tooling has significant performance issues.
If either of you want to discuss this further, we can do so here or though the other Helm communication channels. Specifically, I would encourage you both to reach out on Slack (for async or real time chat), and to join the live weekly Helm meetings. The next Helm dev meeting is in 5 minutes. All the info on how to join these is here: https://github.com/helm/community/blob/main/communication.md
@scottrigby We've since almost a year moved to a custom cached dependency fetcher (which I just migrated to go for an even more significant performance improvement).
The issue wasn't the yaml index per-se (though that does take a part)... The repeated uncached downloads where a far worse issues. Spending a few seconds times 900 charts, is a huge problem.
But we solved it and are this year starting to develop custom tooling for more of our pipelines. Thats not a fault by Helm btw, it's expected that once you reach a certain scale that "off the shelve" tools start hitting limits.
@fredleger Have you tried to test and benchmark this process with charts and dependent charts all stored in OCI? This does not address the feature request for Helm HTTP repos, but it may solve your issue since OCI registries do not work with a single index file like HTTP Helm repos do.
@Ornias1993 this may help your scaling issues too:
Including needing to write custom code for processing helm charts en-masse (900 of them), as Helm tooling has significant performance issues.
If either of you want to discuss this further, we can do so here or though the other Helm communication channels. Specifically, I would encourage you both to reach out on Slack (for async or real time chat), and to join the live weekly Helm meetings. The next Helm dev meeting is in 5 minutes. All the info on how to join these is here: https://github.com/helm/community/blob/main/communication.md
@scottrigby if you look at my original post the issue arrise when using bitnami deps which is from my experience one of the most common use case. Then unless bitnami migrate all their charts to oci registry or if I deploy a mirror registry with oci enabled I don't see how this could help me.
Don't hesitate to correct me if I am wrong.
And for me the point is not the slowness of the download but the fact the download occur at every CT lint
And for me the point is not the slowness of the download but the fact the download occur at every CT lint
This is why we stopped using ct lint completely. first it redownloads the index, then it also redownloads the dependency.
If your scope increases byond a handfull of charts these slowdowns become unworkable. OCI is nice and all, but it just solves the first portion (redownloading index)
Well, OCI solves more than that. But for this particular problem with scaling dependency testing, I see what you mean. Thanks for clarifying.
Question about this:
I would suggest adding a flag (and such option in ct.yaml) to allow skipping it.
If we implemented this way, would relying on the user to do the dep build solve your use case, or would that not be quite enough?
skip the whole step, relying on the user to do dependency build before running ct
Something like a new --skip-dependency-build option to ct lint. If set, would effectively skip this section of the code that does the dependency downloading:
https://github.com/helm/chart-testing/blob/main/pkg/chart/chart.go#L365-L401
And what would propagating this option to the wrapping GitHub action look like? https://github.com/helm/chart-testing-action
Possibly relevant to this discussion:
- https://www.stewartplatt.com/blog/speeding-up-helm-dependency-build/
- https://gitlab.com/gitlab-org/gitlab/-/issues/377681 (particularly the hint section, which links to https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/blob/master/src/bin/auto-deploy#L46-78)
If we implemented this way, would relying on the user to do the dep build solve your use case, or would that not be quite enough?
for me it would fix the original issue yes. My point was not related to using ct lint at scale which is IMHO another issue
@scottrigby if you look at my original post the issue arrise when using bitnami deps which is from my experience one of the most common use case. Then unless bitnami migrate all their charts to oci registry or if I deploy a mirror registry with oci enabled I don't see how this could help me. Don't hesitate to correct me if I am wrong.
@fredleger Replying to this note, you'll be pleased to know all Bitnami charts have been Generally Available as OCI artifacts since spring of this year ✨ https://blog.bitnami.com/2023/04/httpsblog.bitnami.com202304bitnami-helm-charts-now-oci.html
Also relevant to the discussion, this fix is scheduled as part of the Helm 3.14.0 release milestone in January:
- https://github.com/helm/helm/pull/11726
@fredleger, thanks for this clarification.
for me it would fix the original issue yes. My point was not related to using ct lint at scale which is IMHO another issue
@Ornias1993, would this fix your issue as well? Or would the helm dep up performance PR above fix your problem?
If not, please create a more specific issue for yours, and link to this one so we can track which use cases are covered and which aren't.
@fredleger would you like to try your hand at a PR for this? If so, I'd be happy to guide you.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
I've just wanted to join the group of interested people in this and fight away the stale bot.
