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>
17 lines
477 B
YAML
17 lines
477 B
YAML
suite: Test dependency major image bumps
|
|
release:
|
|
name: gitea-unittests
|
|
namespace: testing
|
|
tests:
|
|
- it: "[valkey] Detect major image version upgrades"
|
|
template: charts/valkey/templates/deploy_valkey.yaml
|
|
set:
|
|
valkey:
|
|
enabled: true
|
|
asserts:
|
|
- documentIndex: 0
|
|
matchRegex:
|
|
path: spec.template.spec.containers[0].image
|
|
# IN CASE OF AN INTENTIONAL MAJOR BUMP, ADJUST THIS TEST
|
|
pattern: valkey/valkey:9.+$
|