With `cloudnativePG` in place, the bundled Bitnami `postgresql` sub-chart is the second in-chart way to run a
database, and the worse one. It is a single, non-HA instance without failover, backup or managed major-version
upgrades, and it ships images that Bitnami no longer distributes freely. Keeping it around means maintaining two
code paths for the same job, including the mutual-exclusion assertion between both dependencies and a second set
of DNS, credential and image helpers.
Removing it leaves exactly two supported choices: a CloudNativePG `Cluster` rendered by this chart, or an
external database configured via `gitea.config.database`. Both scale from a single instance to a HA setup -
`cloudnativePG.instances=1` covers the use case the `postgresql` sub-chart served - so nothing is lost besides
the duplication.
BREAKING CHANGE: The `postgresql` sub-chart and all `postgresql.*` values have been removed. There is no
in-place migration path: dump the database of the old `postgresql` release with `pg_dump`, remove the
`postgresql` values, deploy the chart with `cloudnativePG.enabled=true` and restore the dump. Alternatively
point `gitea.config.database` at an externally managed database. Setting `postgresql` now fails the release with
a pointer to the changelog.
Co-authored-by: Copilot <copilot@github.com>
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>
The chart conventions demand camelCase file names, forbid short names like `svc` and require the unit tests to
mirror the template structure. The unit tests followed none of that consistently. Four casings existed side by
side - camelCase (extraInitContainers.yaml), kebab-case (checksum-annotations.yaml), a snake and kebab mix
(init_directory_structure.sh-rootless.yaml) and all caps (HA.yaml) - so there was no pattern to copy when
adding a suite, which is how the inconsistency kept growing.
Three groups of problems are fixed:
- svc-configuration.yaml used exactly the short name the conventions forbid for files and keys.
- Several file names repeated their own directory, for example deployment/deployment-additional-config.yaml and
metric-secret/metrics-secret-servicemonitor-disabled.yaml, which names the subject three times. The directory
already carries that information, so the file name now only carries the scenario. The default scenario of a
template is named basics.yaml.
- Four suites lived in a directory of a template they do not assert on. They were filed under deployment/
because the deployment is rendered as a side effect, not because it is the subject:
deployment/deprecations.yaml -> deprecation/deployment.yaml
deployment/inline-config.yaml -> config/inlineConfig.yaml
deployment/storage-class-configuration.yaml -> persistentVolumeClaim/storageClass.yaml
deployment/svc-configuration.yaml -> service/configuration.yaml
storage-class-configuration.yaml is the clearest case: a persistentVolumeClaim directory already existed next
to it. The suite titles of the two suites whose subject changed are adjusted accordingly.
The Makefile passed `--file unittests/helm/values-conflicting-checks.yaml`, but that file does not exist in the
tree. `helm unittest` ignores a missing path without a warning, so the flag has been dead for an unknown amount
of time while still suggesting the checks run. It is removed; the `unittests/helm/**/*.yaml` glob would pick
the file up anyway if it ever returns.
The naming rule is written down in the copilot instructions, together with the constraint that the glob matches
only a single directory level, so a suite can never be placed directly in unittests/helm/.
All 49 suites and 267 tests still pass.
Co-authored-by: Copilot <copilot@github.com>
volker.raschekandCopilot