3 Commits

Include renames

Author	SHA1	Message	Date
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