-
Notifications
You must be signed in to change notification settings - Fork 7k
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
Added support for export-values in requirements #3243
Conversation
b1b8747
to
89f6418
Compare
Would you mind writing some documentation on this feature? I don't quite understand the 5 W's for this PR so a little context for users trying to use this new feature would be very helpful. Thank you! |
return err | ||
} | ||
b := make(map[string]interface{}, 0) | ||
// import values from each dependency if specified in import-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.
import should be export in comment
// `imports` | ||
e["subchart1.mytags.back-end"] = "false" | ||
e["subchart1.mytags.front-end"] = "true" | ||
|
||
verifyRequirementsImportValues(t, c, v, e) | ||
} | ||
func verifyRequirementsImportValues(t *testing.T, c *chart.Chart, v *chart.Config, e map[string]string) { |
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.
Can you add separate test for export values that exercises 3 levels of nesting?
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.
Should we consider merging some of the import and export code? Perhaps we can just pass in a func that gets executed in the reqs loop.
Issues go stale after 90d 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. |
Hi @withnale, Hopefully you can pick this back up and I need exactly this 😀 @bacongobbler I think a solid use-case here is using generic charts for multiple deployments. I have a service-oriented application and I want the ability to deploy everything at once. This means I have a I was looking at this syntax, but the syntax above would work just as well: dependencies:
- name: web
version: 1.0.0
repository: "https://example.com/charts"
values: website1.com.yaml
- name: web
version: 1.0.0
repository: "https://example.com/charts"
values: website2.com.yaml |
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. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@bacongobbler @withnale I believe this functionality is very useful for a few use-cases. I'm happy to pick this up if there's confidence that it will be merged? /reopen |
@bacongobbler - it's been a long time and I kinda thought this had been merged, but now I actually need it again! If I update the PR is it likely to be merged in? |
/reopen |
See issue #3242
There is a need for an
export-values
method when working with requirements.The attached PR approaches this by mimicking the
import-values
functionality but in the other direction - allowing you to specify the tree in the parent chart you wish to export into the values of the child chart.It also allows you to ringfence settings to a duplicate (aliased) subchart, as can be seen in the example below:Obviously, this simple use case can be achieved through other methods - it's when there are many requirements using a mix & match of various parent values that this change become effective.