-
Notifications
You must be signed in to change notification settings - Fork 65
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
feat: Allow specifying additional labels to be applied to all helm chart resources #183
feat: Allow specifying additional labels to be applied to all helm chart resources #183
Conversation
…sources This is added as a top-level `labels` map within the values file. If it is populated, these labels will be added to the storageclass. It is also added to the 'localpv.labels' variable, already included within every resource besides the storageclass. Signed-off-by: Andrew Lavery <laverya@umich.edu>
Signed-off-by: Andrew Lavery <laverya@umich.edu>
Is this something that you would consider? |
We shall take a look. Thanks for this. |
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.
LGTM. But merging helm chart changes would release a new chart. The CI will be reworked in the future to accomodate helm chart PRs.
We'll take this in during our next release cycle. There's plans for a release in August.
Sounds good, thank you for the review/approval/promise of future merging! |
Thank you, and have a happy Fourth of July! |
Thank you, and wish you the same :) |
* Allow specifying additional labels to be applied to all helm chart resources This is added as a top-level `labels` map within the values file. If it is populated, these labels will be added to the storageclass. It is also added to the 'localpv.labels' variable, already included within every resource besides the storageclass. Signed-off-by: Andrew Lavery <laverya@umich.edu> Signed-off-by: Niladri Halder <niladri.halder26@gmail.com> * Add pod priorityClassName Signed-off-by: Bernard Gütermann <bernard.gutermann@sekops.ch> Signed-off-by: Niladri Halder <niladri.halder26@gmail.com> * refactor(chart): refactor implementation for adding extra labels to all chart resources Signed-off-by: Niladri Halder <niladri.halder26@gmail.com> * refactor(chart): refactor implementation for adding priorityClassName Signed-off-by: Niladri Halder <niladri.halder26@gmail.com> * fix(charts): use the correct slack channel link Signed-off-by: Niladri Halder <niladri.halder26@gmail.com> * chore(changelog): add changelog entries for PRs 182 & 183 Signed-off-by: Niladri Halder <niladri.halder26@gmail.com> * ci: pin medyagh/setup-minikube runs to ubuntu-22.04 (#229) Signed-off-by: Niladri Halder <niladri.halder26@gmail.com> --------- Signed-off-by: Andrew Lavery <laverya@umich.edu> Signed-off-by: Niladri Halder <niladri.halder26@gmail.com> Signed-off-by: Bernard Gütermann <bernard.gutermann@sekops.ch> Co-authored-by: Andrew Lavery <laverya@umich.edu> Co-authored-by: Bernard Gütermann <bernard.gutermann@sekops.ch>
Why is this PR required? What issue does it fix?:
There is currently no way to specify additional labels to be applied to the resources in the chart - only the pod itself, not even the deployment that creates those pods.
What this PR does?:
Adds a top-level
labels
map within the values file. If it is populated, these labels will be added to the storageclass directly, and also to the 'localpv.labels' variable, which is already included within every resource besides the storageclass.Does this PR require any upgrade changes?:
No
If the changes in this PR are manually verified, list down the scenarios covered::
I rendered the yaml with
helm template ./deploy/helm/charts
with both an empty and populatedlabels
map, and validated that labels were created in the approprate places.Any additional information for your reviewer? :
Mention if this PR is part of any design or a continuation of previous PRs
Checklist:
<type>(<scope>): <subject>
PLEASE REMOVE BELOW INFORMATION BEFORE SUBMITTING
The PR title message must follow convention:
<type>(<scope>): <subject>
.Where:
Most common types are:
*
feat
- for new features, not a new feature for build script*
fix
- for bug fixes or improvements, not a fix for build script*
chore
- changes not related to production code*
docs
- changes related to documentation*
style
- formatting, missing semi colons, linting fix etc; no significant production code changes*
test
- adding missing tests, refactoring tests; no production code change*
refactor
- refactoring production code, eg. renaming a variable or function name, there should not be any significant production code changes*
cherry-pick
- if PR is merged in master branch and raised to release branch(like v0.4.x)IMPORTANT: Please review the CONTRIBUTING.md file for detailed contributing guidelines.