-
Notifications
You must be signed in to change notification settings - Fork 24
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
Support for semantic versioned charts #48
Comments
Thanks for raising this! I agree this is something we should fix. One pain point will be that Helm charts strictly use semver with extensions like In Python we typically use PEP440 which is less restrictive and covers semver so we could use There seems to also be python-semver which we could absolutely add as a dependency, but while that handles semver it also doesn't seem to support the extended grammar (xref python-semver/python-semver#241). So in the short term, I expect we could add some support for semver today with either of these libraries. Given that So I don't think we can get to a place where your example with |
Hello, today I've just stumbled upon this and I'd like to drop my 2 cents. While I understand a proper implementation of semver parse could offer some benefits, especially in the long run, it seems we could complete a significant iteration in a much simpler way.
so it is indeed very possible that using a glob instead of dependency version could solve the vast majority of use cases: semver notations is already properly resolved by helm itself and this should Just Work in dependency_path = glob.glob(os.path.join(
chartdir, "charts", f"{dependency_name}-*.tgz",
)) What would be left out/not properly work in this case? If we consider such a dependencies snippet where the same chart is alias included more than once with different versions: dependencies:
- alias: redisfoo
condition: redisfoo.enabled
name: redis
repository: https://charts.bitnami.com/bitnami
version: ~16.4.0
- alias: redisbar
condition: redisbar.enabled
name: redis
repository: https://charts.bitnami.com/bitnami
version: ~16.3.0 or indeed two inclusions of two charts with the same name but different repos (unsure if helm would be cool on that tho): dependencies:
- name: george
repository: https://charts.george.site/funky
version: ~16.4.0
- name: george
repository: https://charts.bonzi.buddy/ehi
version: 101.9 then the proposed implementation would very probably miss the right thing with unpredictable effects. Nonetheless I'd dare to say those are very uncommon practice, for sure way less common that using helm semver implementation at its full potential, for which we could consider, in a very far future :P, to eg. gopy wrap the very semver library so we know we don't lag/mismatch stuff. What do you think? Thank you, regards |
This code is what is relevant for this error, the error is that frigate assumes the .tgz file added to the charts/ folder after Lines 58 to 74 in 4153bf5
I think helm chart works like this, that anything in the charts folder is considered something to be installed, so if there is a folder called If that is the case, the change of logic in frigate should be to not just look for certain files, but look for all charts. Practically, it is now ignoring subcharts I think, and only accepting external chart dependencies. So, fixing this, would be to fix two separate things. An incremental improvement would be to look for all |
@consideRatio looks like interesting material for starting another issue as it seems a bit off-topic here, nor the proposed lookup suggestion add much value, given that you will have to decide anyway which file to analyze in every loop cycle. What do you think? |
I created #49 to represent the issue about frigate not considering subcharts. I found it related to this issue as it is also a broken expectation on the frigate logic with regards to what charts to document. I think this discussion is highly relevant to this bug, and I also think #44 is relevant to merge as it fixes another bug that also touches this logic if not only to make this code more readable. My idea on how to fix this issue, not addressing #49, would be to not loop over declared dependencies in a charts Chart.yaml, but loop over .tgz files in the charts/ folder. @aogier I did not understand the part about |
@aogier your approach sounds reasonable. The other case I can think of is if you modify the version and run Either way do you have interest in raising a PR to implement this/ |
@jacobtomlinson I can confirm |
Are there any updates to this issue? It would be nice to get this working. I'm not a python guy, but if noone is working on this I can take a look when I get time. |
@verenion you can start from there - it currently works, I only lacked enough motivation to push another PR because others' conduct but that code could still be helpful ;) |
Frigate doesn't seem to work if a chart requirement is not specified directly, and instead uses a range:
We have this in our Chart.yaml:
Helm update runs fine:
Frigate fails with:
There is a
./charts/common-1.7.4.tgz
.The text was updated successfully, but these errors were encountered: