5 Commits

Include renames

Author	SHA1	Message	Date
volker.raschekandCopilot	55964679ea	feat(deployment)!: move deployment.env to deployment.gitea.env and add deployment.enabled ... The `deployment` dict mixes values that apply to the Deployment object itself (`annotations`, `labels`, `affinity`, `terminationGracePeriodSeconds`) with values that apply to a single container. `deployment.env` was the only container-scoped key, which made it unclear which container it targets once further containers get their own configuration. Grouping container-scoped values under `deployment.gitea` establishes a per-container namespace and leaves room for sibling sections without another breaking rename later. The value ordering in `values.yaml` is aligned with the chart conventions (`enabled`, `annotations`, `labels` first). `deployment.enabled` is introduced and wired up in the template so the Deployment can be skipped entirely. This allows the chart to be used for rendering only the surrounding resources, e.g. when the workload itself is managed elsewhere. A deprecation check is added so that existing installations fail fast with an actionable error message instead of silently dropping their environment variables, which would otherwise surface as hard-to-debug runtime misconfiguration. Unit tests cover the disabled Deployment, the propagation of `deployment.gitea.env` into all init containers and the Gitea container, and the deprecation checks for `affinity` and `deployment.env`. BREAKING CHANGE: `deployment.env` no longer exists. Use `deployment.gitea.env` instead. Installations that still set `deployment.env` will fail unless `checkDeprecation` is set to `false`. Co-authored-by: Copilot <copilot@github.com>	2026-09-04 11:05:29 +02:00
volker.raschekandCopilot	150c08eabc	feat(deployment)!: move affinity to deployment.affinity ... Moving `affinity` into the `deployment` dict groups it with the other Deployment-specific values and prepares a consistent structure for further migrations of pod-level settings. A deprecation check is added so that existing installations fail fast with an actionable error message instead of silently dropping the affinity rules, which would otherwise lead to pods being scheduled on unintended nodes. BREAKING CHANGE: `affinity` no longer exists. Use `deployment.affinity` instead. Installations that still set `affinity` will fail unless `checkDeprecation` is set to `false`. Co-authored-by: Copilot <copilot@github.com>	2026-09-04 09:12:58 +02:00
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>	2026-09-03 20:43:53 +02:00
volker.raschekandCopilot	3535611d4d	feat(secrets)!: replace the signing object with secrets.gpg ... The `signing` object was the last Secret-related configuration living outside of the `secrets` section introduced in the previous commit. Keeping it separate meant that the GPG key Secret was the only one without configurable annotations, labels and a proper `existingSecret` reference, and users had to learn two different conventions for the same concept. `signing` is therefore removed and fully replaced by `secrets.gpg`: signing.enabled -> secrets.gpg.enabled signing.gpgHome -> secrets.gpg.new.gpgHome signing.privateKey -> secrets.gpg.new.privateKey signing.existingSecret -> secrets.gpg.existingSecret.{enabled,secretName} `gpgHome` is now stored as a key inside the GPG key Secret and consumed via `secretKeyRef` instead of being rendered as a plain environment variable value. This keeps the whole GPG configuration in a single object, so an operator can hand over one Secret that fully describes the signing setup instead of splitting it across values and Secret data. The key names of an externally provided Secret are configurable via `secrets.gpg.existingSecret.gpgHomeKey` and `secrets.gpg.existingSecret.privateKeyKey`, because chart-defined key names cannot be assumed for Secrets that are managed by an external system such as an operator or a secret store. To avoid silently ignoring a now unknown value, `deprecation.yaml` fails the render when `signing` is still set and points to `secrets.gpg`. As with the other deprecation guards it can be bypassed via `checkDeprecation: false`. The unit tests are migrated accordingly and the `GNUPGHOME` assertions now verify the `secretKeyRef` shape. Two new cases cover custom `gpgHomeKey` and `privateKeyKey` values of an existing Secret. The README gains a `To 13.0.0` upgrade section documenting this change together with the `secrets.*` block and the Secret renames of the preceding commits. BREAKING CHANGE: The `signing` object has been removed and is replaced by `secrets.gpg`. Rendering fails if `signing` is still set. Secrets referenced via `secrets.gpg.existingSecret` now additionally require a `gpgHome` key next to `privateKey`. Co-authored-by: Copilot <copilot@github.com>	2026-09-03 17:36:33 +02:00
justusbunsi	c27140c4cb	Add deprecation fail-safe for Chart templating (#269) ... With release 5.0.0 there are so many deprecations and breaking changes that it is probably a good way to assist the users with values migration before breaking their environments. This adds another template file that doesn't render anything but ensures the removal of dropped or deprecated settings from customized values files. For when it is necessary, this check can be disabled via new setting `checkDeprecation`. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/269 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: wxiaoguang <wxiaoguang@noreply.gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>	2021-12-23 00:25:32 +08:00