-
Notifications
You must be signed in to change notification settings - Fork 206
docs: adding expose depoyed chart hip #421
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
base: main
Are you sure you want to change the base?
docs: adding expose depoyed chart hip #421
Conversation
Signed-off-by: Andrew Shoell <mrlunchbox777@gmail.com>
Signed-off-by: Andrew Shoell <mrlunchbox777@gmail.com>
Signed-off-by: Andrew Shoell <mrlunchbox777@gmail.com>
Signed-off-by: Andrew Shoell <mrlunchbox777@gmail.com>
Signed-off-by: Andrew Shoell <mrlunchbox777@gmail.com>
Signed-off-by: Andrew Shoell <mrlunchbox777@gmail.com>
ef34886 to
4c65745
Compare
|
@scottrigby @gjenkins8 here is the hip we talked about at contribfest |
|
+1 |
|
Some notes that were brought up to improve the proposal were to:
|
Here is an example of getting flux CRs to control if an upgrade job runs. It was part of this MR. It was used for a default name change on immutable resources by deleting them in a hook. |
Signed-off-by: Andrew Shoell <mrlunchbox777@gmail.com>
d819dc7 to
b48d8f5
Compare
|
|
||
| ## Rejected Ideas | ||
|
|
||
| - **Full Release Object:** Security/performance concerns; chart metadata sufficient |
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.
my main thought is, would you not also want to expose the values of helm history to check things like whether a previous release was successful?
Some thoughts about this: What about adding "History" key to the existing .Release built-in: .Release.History when a --release-history-depth flag is passed?
This could be a filtered version of the Release object that's currently stored in helm release secrets by default.
Agree that the full release object could cause performance issues. perhaps this could be mitigated by:
- any history might be best to opt-into with a flag (default history level 0 rather than 1 as currently proposed)
- including only a filtered subset of the release object, omitting potentially very large data like templates, manifest etc.
Not yet sure what security concerns adding the Release object would add that other built-ins don't already have (eg, .Values, .Files, etc). But good to consider here.
| @@ -0,0 +1,199 @@ | |||
| --- | |||
| hip: 0027 | |||
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 should be "9999", see https://github.com/helm/community/blob/main/hips/hip-0001.md
Adding a HIP to expose the currently deployed chart at render time.