-
Notifications
You must be signed in to change notification settings - Fork 157
add support for optional secrets using flag optional-secrets #160
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?
Conversation
|
Hi @arttor! It took me a while, but I found time to push this PR. What do you think? Does it suit the project scope? Does it lack anything? |
arttor
left a comment
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.
hi, thank you for this proposal.
Can you please explain how optional secrets will be used?
I am asking only because i had different understanig based on our disucssion in #152.
My understanding was that:
- User provides list of secret names as flag. These secrets should be created externally and not be a part of Helm chart.
- Helmify will ignore listed secrets entirely and will not create any templates for these secrets
- Helmify will find secret usages in other resoruces like Pod and replace it with a name of external secret, which will be stored in
values.yamlasexternalSecrets: <secret_name>: "<secret_name>"
|
Hi @arttor what do you think? Can this be merged? |
|
sorry for not responding. But i am a bit struggling to understand the feature by looking at the code. Can you please explain what it does and what is the use-case? |
|
Hi @arttor sorry, this went over my head. Imagine a registryCredentials secret. With this approach, the user installing the chart could decide to either install the chart with the value In my opinion this is useful because it allows users to either have the comfort of having a secret created upon install, or if they want they can define the secret themselves and maybe use something like ExternalSecrets to manage it. |
Add support for optional secrets which are not required by default.
related to #152