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>
Every chart-managed init container already exposes its own `volumeMounts` through the linked configuration block, so
`extraInitVolumeMounts` added a second way to express the same thing. It was also the only mount setting left outside
of `deployment`, which made the mount configuration harder to discover than it needed to be.
Worse, the name promised more than it delivered. The value was only injected into the four linked init containers and
never reached an init container added through `deployment.initContainers[].container`, even though that is exactly
what a reader would expect from a setting called "extra init volume mounts". The documented use case does not need
the fan-out either: the sample `initPreScript` copies the Postgres client certificate onto the `data` volume, so a
single mount on `deployment.initDirectories.volumeMounts` is enough and the later containers pick it up via /data.
With the value gone the `gitea.init-additional-mounts` helper has no purpose left and is removed together with its
four call sites, which now rely on the already existing `volumeMounts` block of the respective init container.
Co-authored-by: Copilot <copilot@github.com>
`extraVolumeMounts` was deprecated in 6.0.0 in favour of separate mounts for the init phase and the runtime container,
but it was never removed. It had turned into a trap: both helpers treated it as a fallback that silently disappeared as
soon as `extraInitVolumeMounts` respectively `deployment.gitea.volumeMounts` contained a single entry, so adding one
new mount could unmount everything configured through the old value. The documented successor
`extraContainerVolumeMounts` had meanwhile been removed itself, which left the deprecation note pointing at a value
that already fails the deprecation check.
Removing it makes the mount configuration explicit: `extraInitVolumeMounts` for the init containers,
`deployment.gitea.volumeMounts` for the Gitea container, and both when a volume is needed in both places.
The GPG init container used `extraVolumeMounts` directly instead of the shared helper and therefore ignored
`extraInitVolumeMounts`, unlike the three other init containers. It now uses `gitea.init-additional-mounts` as well.
Co-authored-by: Copilot <copilot@github.com>
The value only ever populated the `spec.ingressClassName` field of the Ingress resource, so the shortened name was a
needless deviation from the Kubernetes API. `ingress.className` carried a `DEPRECATED` marker since #679, but that
marker was a leftover: the rename to the canonical name was proposed there, rejected during review and the follow-up
commits only removed the half-merged template fallback. The marker stayed behind for a year while the value remained
the one and only way to set the Ingress class, which made the documentation actively misleading.
The deprecation guard uses `hasKey` instead of a truthiness check on purpose. The previous chart default was an empty
string, so vendored values files tend to carry `ingress.className: ""` verbatim. A truthiness check would silently
ignore those and leave users wondering why their Ingress class is no longer applied.
Co-authored-by: Copilot <copilot@github.com>
The chart shipped a `helm test` hook Pod that ran `wget` against the HTTP Service. It only proved that the
Service resolves and answers on the configured port, which the readiness probe already covers, so it carried
no information the release did not have anyway. In exchange it pulled `busybox:latest` into clusters -- an
unpinned, mutable tag in a chart that otherwise pins every image digest -- and it kept a Pod spec alive that
had to track every change to the security context and hostUsers helpers.
Removing the template also removes the `test.*` values that only existed to configure it, so the parameter
table in the README was regenerated accordingly.
A guard in `deprecation.yaml` catches leftover `test` values instead of silently ignoring them. Its message
deviates from the surrounding guards on purpose: there is no replacement value to point at, so it states that
the feature is gone rather than suggesting a migration target.
BREAKING CHANGE: `helm test <release>` no longer executes any test for this chart, and the values
`test.enabled`, `test.image.name` and `test.image.tag` have been removed. Installations that still set them
will fail with a descriptive error until the keys are dropped, unless `checkDeprecation` is set to false.
Co-authored-by: Copilot <copilot@github.com>
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>
volker.raschekandCopilot