3 Commits

Include renames

Author	SHA1	Message	Date
volker.raschekandCopilot	1b82a15b7f	feat!: replace postgresql-ha with CloudNativePG ... The bundled `postgresql-ha` sub-chart was the only HA-ready database option, but it pinned us to a Bitnami chart whose images are no longer freely distributed, and it bundled repmgr and pgpool into the release. Operating a Postgres cluster through a Helm release also means the chart has to reimplement failover, backup and upgrade orchestration that a dedicated operator already solves. CloudNativePG is the de-facto standard operator for Postgres on Kubernetes and handles instance management, streaming replication, switchover and rolling upgrades itself. The operator is deliberately *not* part of this chart: cluster-scoped CRDs and controllers do not belong into an application release and would conflict with an operator that is already installed. The chart only renders the namespaced `Cluster` resource, so the operator can be managed independently. Because the operator cannot be assumed to be present, `cloudnativePG.enabled` defaults to `false`. Existing users of `postgresql` or an external database are therefore unaffected. Credentials follow the chart-wide `secrets.*` convention. Only the password is read from a Secret, because CloudNativePG requires `bootstrap.initdb.database` and `bootstrap.initdb.owner` as literals in the `Cluster` spec and cannot resolve them from a Secret. The password is injected into the `init-app-ini` container as `GITEA__database__PASSWD` instead of being written into the generated `app.ini`. BREAKING CHANGE: The `postgresql-ha` sub-chart and all `postgresql-ha.*` values have been removed. There is no in-place migration path between the two deployments: dump the database of the old `postgresql-ha` release with `pg_dump`, remove the `postgresql-ha` values, deploy the chart with `cloudnativePG.enabled=true` and restore the dump. Setting `postgresql-ha` now fails the release with a pointer to the changelog. Co-authored-by: Copilot <copilot@github.com>	2026-10-04 00:18:34 +02:00
volker.raschekandCopilot	64c2f1a9cc	fix(secrets): render config and init secrets as data to prune removed keys ... Both Secrets rendered their payload via `stringData`. That field is write-only: the API server decodes it into `data` and does not persist `stringData` itself. Helm's three-way merge therefore generates a deletion patch that targets `stringData`, while the live object only ever carries `data` - so a key that disappears from the rendered manifest is never pruned and survives every upgrade. Unlike the inline-config Secret fixed in #1110, the keys here are driven by the files in `scripts/init-containers/**` rather than by user values, so the bug is latent rather than acute. It still bites whenever a script is removed or renamed in the chart: the stale key stays in the Secret and keeps being mounted into the init containers. The two inline scripts of the init Secret were YAML block scalars and had to be moved into `define` blocks to be pipeable through `b64enc`. The bodies are dedented by four columns accordingly, and `trimAll "\n"` reproduces the chomping semantics of the previous `|-` scalars. Rendering was diffed against the previous revision for defaults, rootless, initPreScript, GPG, admin, LDAP, OAuth and all valkey variants - the decoded payloads are byte-identical, so no init script changes behaviour. Unit tests now read the payloads from `data.*` with `decodeBase64: true` and assert that `stringData` no longer exists, to catch a regression early. See: https://gitea.com/gitea/helm-gitea/issues/1109 See: https://gitea.com/gitea/helm-gitea/pulls/1110 Co-authored-by: Copilot <copilot@github.com>	2026-10-03 17:34:48 +02:00
volker.raschekandCopilot	552fe8c56e	refactor(templates): move the templates out of the gitea subdirectory ... The `templates/gitea` subdirectory did not group anything meaningful, since every template of this chart belongs to Gitea. It only duplicated the chart name in every path and forced the unit tests to spell out `templates/gitea/<name>.yaml`, while `_helpers.tpl` and `NOTES.txt` already lived directly in `templates`. All templates now live in `templates`, which matches the layout of the bundled sub-charts and the Helm defaults. The checksum helper in `templates/_secrets.tpl` built its include path from `$root.Template.BasePath` and therefore carried the subdirectory in a `printf` format string instead of a literal path. Without adjusting it the chart failed to render with "no template gitea/templates/gitea/secret_config.yaml associated with template gotpl". Co-authored-by: Copilot <copilot@github.com>	2026-09-14 20:28:17 +02:00