e8f3a058ceadc0379ab13b9b5199ee1bbf3fe11f
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  volker.raschekandCopilot
|
e8f3a058ce
|
feat(deployment)!: configurable init containers and Secret checksum lookup
The chart-managed init containers were hardcoded inside `deployment.yaml`. Their image, environment, resources, security context and volume mounts could not be adjusted individually, and custom init containers could only be prepended or appended as a whole via `preExtraInitContainers`/`postExtraInitContainers`. The init containers are now rendered from `deployment.initContainers`, an ordered list whose entries either `link` a chart-managed init container (`initDirectories`, `initAppIni`, `initConfigureGPG`, `initConfigureGitea`) or provide a free-form `container` definition. This allows custom containers at any position and makes the execution order explicit. Each linked init container has its own configuration block in `values.yaml` and falls back to `deployment.gitea.securityContext` and `initContainers.resources` when unset. To support per-container images, `gitea.image` was split into the generic helper `gitea.image.name`, which renders an arbitrary `image` dict instead of only `deployment.gitea.image`. The pod annotations moved from `deployment.yaml` into the new helper `gitea.pod.annotations`. The SHA sum annotations now also cover user-provided Secrets: their content is unknown to the chart, so the Secret is read from the cluster via Helm's `lookup` function. Chart-managed Secrets keep using the rendered manifest, because the cluster still holds their pre-upgrade state during rendering. Because `lookup` requires `get` permission on Secrets and silently returns nothing during client-side rendering (`helm template`, `--dry-run`, Argo CD without a live cluster), `addSHASumAnnotation` now defaults to `false`. The trade-offs are documented in the README so users can make an informed decision. BREAKING CHANGE: `preExtraInitContainers` and `postExtraInitContainers` have been removed. Add an entry with a `container` key before or after the linked init containers in `deployment.initContainers` instead. BREAKING CHANGE: `secrets.<secret>.addSHASumAnnotation` now defaults to `false`. Set it to `true` explicitly to keep the rollout trigger on Secret changes. Co-authored-by: Copilot <copilot@github.com> |
||
|
volker.raschekandCopilot
|
229ba12744
|
feat(secrets)!: replace the gitea.admin object with secrets.admin
The admin user was the last piece of credential handling that lived outside of the `secrets` section. Worse, it was the
only credential the chart rendered as a plain environment variable value into the Deployment: unless an existing Secret
was referenced, username and password ended up in the pod spec in clear text, readable by anyone who can `get` or
`describe` the Deployment.
`gitea.admin` is therefore removed and fully replaced by `secrets.admin`:
gitea.admin.username -> secrets.admin.new.username
gitea.admin.password -> secrets.admin.new.password
gitea.admin.email -> secrets.admin.new.email
gitea.admin.passwordMode -> secrets.admin.passwordMode
gitea.admin.existingSecret -> secrets.admin.existingSecret.{enabled,secretName}
The chart now always creates a dedicated `<fullname>-admin` Secret and the Deployment consumes `GITEA_ADMIN_USERNAME`,
`GITEA_ADMIN_PASSWORD` and `GITEA_ADMIN_EMAIL` via `secretKeyRef`. This removes the clear text credentials from the pod
spec and makes the chart-managed and the externally provided case behave identically, which previously diverged.
The email address moved into the Secret as well. It used to be interpolated directly into the init script, so changing
it rewrote the init Secret, and an operator handing over admin credentials could not supply it. The key names of an
externally provided Secret are configurable via `secrets.admin.existingSecret.{emailKey,passwordKey,usernameKey}`,
because chart-defined key names cannot be assumed for Secrets managed by an external system such as a secret store.
Admin handling was previously skipped implicitly when neither an existing Secret nor a username and password were set.
This implicit behaviour is replaced by the explicit `secrets.admin.enabled` flag, so disabling it no longer requires
blanking out unrelated values.
`gitea.admin.passwordMode` validation moved from `_helpers.tpl` to `_secrets.tpl` as
`gitea.secret.admin.passwordMode` to keep all Secret related helpers in one place. `deprecation.yaml` fails the render
when `gitea.admin` is still set and points to `secrets.admin`.
New test suites cover the rendered admin Secret, the `secretKeyRef` wiring, custom key names of an existing Secret and
the password mode validation. The `secret_admin.yaml` template is registered in every suite that renders the Deployment,
as helm-unittest requires templates referenced via `$.Template.BasePath` to be listed explicitly.
BREAKING CHANGE: The `gitea.admin` object has been removed and is replaced by `secrets.admin`. Rendering fails if
`gitea.admin` is still set. Secrets referenced via `secrets.admin.existingSecret` now additionally require an `email`
key next to `username` and `password`.
Co-authored-by: Copilot <copilot@github.com>
|
||
|
volker.raschekandCopilot
|
4d82f17ce6
|
feat(secrets): make every Secret configurable via a secrets.* block
Until now the Secrets rendered by this chart were not configurable at all. Their labels were fixed to the chart defaults, they could not carry annotations, and there was no way to hand in a Secret that is managed outside of the chart - except for the GPG key, which had its own special case via `signing.existingSecret`. Users who manage their secrets with an external operator (e.g. External Secrets, Sealed Secrets) or who need annotations for tooling such as Reloader or Kyverno had no option but to fork the chart. A `secrets` section is introduced with one entry per Secret (config, gpg, init, inlineConfig, metrics), each offering: addSHASumAnnotation add a checksum annotation to the pod template (default: true) existingSecret.enabled reference a Secret that is not managed by this chart existingSecret.secretName name of that Secret new.annotations annotations for the Secret created by the chart new.labels additional labels for the Secret created by the chart The `new` sub-key keeps the properties of a chart-managed Secret clearly separated from the properties of a referenced one, so it is obvious which settings are ignored once `existingSecret` is enabled. `secretName` rather than `name` mirrors the field the value ends up in, the `secretName` of a pod volume. The `gitea.secret.*.name` helpers resolve to the user-provided name when `existingSecret` is enabled, which means the Deployment volumes and the ServiceMonitor credentials pick it up without further changes. Enabling `existingSecret` without a name fails the render with a message naming the full values path, because Helm would otherwise silently create a Secret under the referenced name and overwrite it. Only two of the five Secrets had a checksum annotation before, so changes to the init scripts, the GPG key or the metrics token did not trigger a rollout. Annotations for all five are now rendered, each gated by `addSHASumAnnotation` and skipped for Secrets the chart does not manage. Two side effects had to be preserved when a Secret is no longer rendered: - secret_config.yaml carries the HA assertions (RWX access mode, issue/repo indexer, mutually exclusive PostgreSQL dependencies) inside its `assertions` field. They are extracted into `gitea.config.assertions` and evaluated before the guard, otherwise providing an own config Secret would silently disable chart-wide validation. - secret_inlineConfig.yaml populates `.Values.gitea.config` as a side effect of `gitea.inline_configuration`. Without evaluating it, even NOTES.txt fails on `.Values.gitea.config.cache`. The include therefore runs independently of the guard as well. `signing.existingSecret` keeps working; `secrets.gpg.existingSecret` takes precedence over it. The error message raised for an enabled but unconfigured signing setup now lists all three options. Test suites rendering the Deployment have to declare the Secret templates it checksums, hence the added `templates:` entries. unittests/helm/deployment/extraInitContainers.yaml set `signing.enabled` without a key or an existing Secret - a combination that fails a real `helm install` and only went unnoticed because the Deployment never rendered secret_gpg.yaml before. Co-authored-by: Copilot <copilot@github.com> |