-
Notifications
You must be signed in to change notification settings - Fork 187
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
Add ValuesFiles
to HelmChart spec
#305
Conversation
I can recreate this test failure locally at least. I'll need to invest some time on getting that suite up and running properly so I can see what is causing the, I assume, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for submitting this @arbourd 🥇
Did a quick first round of review with some minor comments.
Nice work so far, @arbourd! I like the idea of having the ability to use multiple override values files combined. |
I'm looking into this and will get back to you if I can figure it out. |
Because the test suite is not working this PR is now blocked by #332 |
if v == "values.yaml" { | ||
valuesMap = transform.MergeMaps(valuesMap, helmChart.Values) | ||
continue | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default values are not available from the filesystem, only via helmChart.Values
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please note this @relu
Okay so finally this passes all tests, for both Git repositories and Helm repositories. As I was working on it last night, I had a realization that way we handle default values is problematic. I think we should always merge the default values. For most Helm users, I think that if someone is expecting a fully-declarative (no merging) values override they should implement the best practise of duplicating it exactly (as Bitnami used to do for example). |
This behavior was chosen because we also have a No strong opinion on (not) changing this, so would welcome @relu's thoughts. |
The way I see it is that @arbourd you mentioned that Argo and other tools are doing it differently, I don't think that's the case. Argo also has the ability to supply multiple values files at the level of the release, while we support that as well since |
We use ArgoCD in production right now and this what the production application CRD looks like: spec:
destination:
namespace: default
source:
path: ./path-to-chart
repoURL: [email protected]:org/repo.git
targetRevision: HEAD
helm:
valueFiles:
- values-production.yaml The default values are implicitly included in the The trade off for this additional flexibility (being able to exclude the default values) is a difference in expectations from Helm itself, which may lead to confusion from Helm users new to Flux. That being said, I also don't have a strong opinion on this. I brought it up on this PR because if we were to change it, this would be the time (already changing the spec). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks OK to me, thank you very much @arbourd 🥇
Signed-off-by: Dylan Arbour <[email protected]>
Let me know if you need anything else to make it more than OK 😁 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All good from my side as well 🙌
There are two additional things @arbourd:
|
Do we need to prerelease of the source-controller for that @hiddeco? |
@arbourd you can create a PR that works with an API dependency from |
Allows the use of more than values file to be declared and used in a
HelmRelease
,HelmChart
.Closes #291