Create official helm chart for safe-settings #580
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This helm chart has taken much inspiration from https://github.com/decyjphr-org/charts/tree/main/helm-charts/safe-settings, but it differs in one main way. It don't force the user to put any secrets directly in the values files. Instead, I make it possible to either set the environment variables or point to any Kubernetes secret you want. I assume that the secret already exists, how this secret is up to the user of the helm chart.
In a GitOps world, I would suggest something like
Or if you want, you can still add the secret through Kubernetes.
This of course makes it harder to use the helm chart, but it will help to enforce best practices. We can of course extend this PR to support a similar Kubernetes secret injection that the current helm chart supports. But it needs to be able to disable this feature.
I have created a helm chart so you can try it out if you want
helm upgrade -i safe-settings oci://ghcr.io/nissessenap/helm-charts/safe-settings --version 2.1.0
TODO
If we instead would trigger on release https://github.com/NissesSenap/safe-settings/blob/main-enterprise/.github/workflows/create-release-2.yml this would work, but I don't want to put too much time in to this unless someone thinks this is worth merging.
Partly fixes #578
Looking forward to your feedback.