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>
The contributor guidelines never defined how a `suite` title has to look, only how an `it` title has to look.
Without a rule five competing schemes grew side by side: `config template | cache config`, `deployment
template (probes)`, `ServiceMonitor template (basic)`, `Test Gateway API httpRoute.yaml` and `Dependency checks
| Customization integrity | valkey`. 24 of the 49 titles started with a lowercase letter, which contradicts the
sentence rule that already applies to the test titles.
More than cosmetics, the missing rule produced three concrete defects:
- `deployment template` was used by both deployment-additional-config.yaml and extraInitContainers.yaml, and
`Init template` by both init_directory_structure.sh.yaml and its rootless counterpart. `helm unittest`
identifies a failing suite by its title, so a failure in either file printed the same header and the report
did not say which file to open.
- deployment/inline-config.yaml was titled `config template`, although it lives in the deployment directory and
asserts on secret_inlineConfig.yaml. It read like a sixth member of the `config template | ...` group.
- persistentVolumeClaim.yaml was titled `PVC template`, using exactly the short name the chart conventions
forbid for files and keys.
All suites now follow `Test <subject> <scenario>`, for example `Test deployment probes` or `Test gateway API
httpRoute`. The subject is the template under test, the scenario is what distinguishes the suite from its
siblings, so every title is unique and sorts next to its related suites. The `Test ` prefix of the Gateway API,
ingress and route suites is kept, because it is the only part of the old schemes that already read as a
sentence; the redundant `.yaml` suffix and the `tests` suffix of the storage class suite are dropped.
The rule is written down in the Unit Tests section of the copilot instructions, so the next suite does not have
to guess which of the five schemes was meant.
Co-authored-by: Copilot <copilot@github.com>
The contributor guidelines require that the title of a unit test is "a short sentence starting with a capital
letter and ending without a period". Only 30 of the 269 titles followed that rule. The remaining ones were
lowercase verb phrases ("renders a deployment"), which made the test output read inconsistently depending on
which suite was running, and made it impossible to tell a convention violation from an intentional style.
All titles are now imperative, capitalized and unquoted-safe:
renders a deployment -> Render a Deployment
should not render when gatewayAPI.enabled is false -> Skip rendering when gatewayAPI.enabled is false
skips gpg volume spec -> Skip the gpg volume spec
The bracketed prefixes of the dependency checks and of the server section suite are kept, because they group
the tests by the chart they assert on. Only the sentence behind the prefix was rewritten.
Beyond the pure capitalization three classes of titles needed real rewording:
- The titles in image-configuration.yaml named a subject instead of a scenario ("default values", "tag
override", "digest and global registry"). They now describe what is rendered.
- init_directory_structure.sh-rootless.yaml carried "it does not chown /data ...", which rendered as
"it it does not chown" in the test output.
- The "should" prefix in the Gateway API and route suites added no information once the title is a sentence.
The title of the GIT_GC_REPOS test lost its embedded double quotes. The title was previously an unquoted YAML
scalar, so the quotes were literal characters; quoting the title turned them into a parse error. The value is
unambiguous without them.
Three byte-identical tests asserting pgpool.adminPassword existed in customization-integrity-postgresql-ha.yaml
- same template, same assertion, same expected value. They were a copy-paste artifact and shared one title, so
two of them are removed. No coverage is lost, which is why the test count drops from 269 to 267.
No snapshot files are tracked and no suite uses matchSnapshot, so retitling cannot invalidate stored snapshots.
Co-authored-by: Copilot <copilot@github.com>
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>
The inline-config Secret used `stringData`. The API server stores it as `data`, so a section removed from `gitea.config` was never pruned from the live Secret, and the init container kept writing it into `app.ini` on every start. With Gitea 28, a leftover `[webhook] ALLOWED_HOST_LIST` overrides `[security]`'s, which breaks webhooks to private hosts.
This renders the Secret as base64 `data` instead.
- `templates/secret_inlineConfig.yaml`: `stringData` → `data` (`b64enc`).
- Unit tests read `data.*` with `decodeBase64: true`; adds a regression test asserting there is no `stringData`.
Note: keys that are already stale from the `stringData` era survive the first upgrade to this version, because Helm's three-way merge never recorded them under `data`. Every removal after that is pruned.
`make unittests-helm`: 261 passed. `helm lint` and `yamllint` are clean.
Co-authored-by: perfectra1n <jonfuller2012@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1110
Co-authored-by: perfectra1n <49838+perfectra1n@noreply.gitea.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>
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>
The files in templates/gitea/ used a mix of naming styles: lowercase concatenations
(poddisruptionbudget.yaml, serviceaccount.yaml, servicemonitor.yaml, pvc.yaml), camelCase
(httpService.yaml, sshService.yaml) and kind-suffixed names (gpg-secret.yaml, metrics-secret.yaml).
It was therefore not obvious from a file name which Kubernetes resource it renders, and the naming
contradicted the camelCase convention the Gateway API templates already follow.
Files are now named after the kind they render, with a lowercase suffix distinguishing several
resources of the same kind:
config.yaml -> secret_config.yaml + secret_inlineConfig.yaml
gpg-secret.yaml -> secret_gpg.yaml
init.yaml -> secret_init.yaml
metrics-secret.yaml -> secret_metrics.yaml
httpService.yaml -> service_http.yaml
sshService.yaml -> service_ssh.yaml
poddisruptionbudget.yaml -> podDisruptionBudget.yaml
pvc.yaml -> persistentVolumeClaim.yaml
serviceaccount.yaml -> serviceAccount.yaml
servicemonitor.yaml -> serviceMonitor.yaml
config.yaml rendered two Secrets from a single file, which forced every unit test to address them via
documentIndex. It is split so that each file renders exactly one resource.
The rendered manifests are unchanged; only file names and the references to them were touched. This
includes the checksum/config annotation in deployment.yaml and all helm unit test suites. The HA guard
assertions had to move from deployment.yaml to secret_config.yaml: Helm sorts templates in reverse
alphabetical order, so secret_config.yaml is now rendered before deployment.yaml and the fail() is
reported for that file directly instead of bubbling up through the include chain of the Deployment.
Users relying on the template paths (e.g. `helm template --show-only` or post-renderers) have to
adjust to the new file names.
Co-authored-by: Copilot <copilot@github.com>
Migrate from bitnamicharts/valkey (and bitnamicharts/valkey-cluster) to the official Valkey Helm chart (https://valkey.io/valkey-helm, v0.10.0).
Changes:
- Remove valkey-cluster dependency and all related values, templates, and unit tests
- Update valkey dependency to use https://valkey.io/valkey-helm
- Adapt _helpers.tpl (valkey.dns, valkey.port, valkey.servicename) to the new chart's service naming and value structure
- Update values.yaml to match the new chart's configuration schema (auth.aclUsers instead of global.valkey.password, service.port instead of primary.service.ports.valkey, dataStorage instead of
primary.persistence)
- Update all affected unit tests
- Update README documentation
BREAKING CHANGE: valkey-cluster support has been removed. Users previously relying on valkey-cluster must migrate to standalone valkey or an external Redis-compatible service. The valkey values structure
has changed: `valkey.global.valkey.password` is now `valkey.auth.aclUsers.default.password`, and `valkey.primary.service.ports.valkey` is now `valkey.service.port`.
---------
Co-authored-by: rishub <183523+rishub@noreply.gitea.com>
Co-authored-by: rishub <itsrishub@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1097
Co-authored-by: Markus Pesch <markus.pesch@cryptic.systems>
Add full Gateway API support for exposing Gitea via HTTPRoute, TCPRoute, BackendTLSPolicy, and ClientSettingsPolicy resources.
New templates:
- `httpRoute.yaml` — renders an HTTPRoute with configurable
parentRefs, hostnames, and rules (defaults to PathPrefix `/`)
- `tcpRoute.yaml` — renders a TCPRoute for SSH traffic
- `backendTLSPolicy.yaml` — renders a BackendTLSPolicy for
encrypted backend connections with required validation config
- `clientSettingsPolicy.yaml` — renders an NGINX Gateway Fabric
ClientSettingsPolicy to raise the request body size limit
Infrastructure:
- `gatewayAPI.enabled` global toggle gates all resources
- Resources grouped under `gatewayAPI.core.*` and `gatewayAPI.nginx.*`
- Helper templates extracted into dedicated `_*.tpl` files
- Service name helpers (`gitea.service.http.name`, `gitea.service.ssh.name`)
extracted into `_services.tpl`; service templates renamed to camelCase
- `ROOT_URL`, `DOMAIN`, and `SSH_DOMAIN` auto-resolve from
`httpRoute.hostnames[0]`; `httpRoute.tls` switches to `https`
Documentation:
- New `docs/gateway-api.md` with topology examples, BackendTLSPolicy
setup, sectionName guidance, SSH considerations, and NGINX body
size limit configuration
- `.github/copilot-instructions.md` with project conventions
- README parameter table auto-generated via `make readme`
Tests:
- Helm unit tests for all four new resource templates
- Config tests for hostname/TLS resolution from Gateway API values
Co-authored-by: Todd Marimon <toddmarimon@gmail.com>
### Description of the change
Add options to values.yaml to make chart easier to install in restricted openshift environments
### Benefits
more people can run this
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [ ] Breaking changes are documented in the `README.md`
- [x] Helm templating unittests are added (required when changing anything in `templates` folder)
- [ ] Bash unittests are added (required when changing anything in `scripts` folder)
- [x] All added template resources MUST render a namespace in metadata
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1063
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.com>
Co-committed-by: techknowlogick <techknowlogick@gitea.com>
<!--
Before you open the request please review the following guidelines and tips to help it be more easily integrated:
- Describe the scope of your change - i.e. what the change does.
- Describe any known limitations with your change.
- Please run any tests or examples that can exercise your modified code.
Thank you for contributing! We will try to review, test and integrate the change as soon as we can.
-->
### Description of the change
Migrates from Redis to Valkey.
### Benefits
The Redis License is changing from BSD-3-Clause to RSALv2 and SSPLv1 which are not open source under the OSI definition. We should consider open-source alternatives as a default replacement for Redis.
### Possible drawbacks
Large scale change, potentially breaking.
### Applicable issues
https://github.com/go-gitea/gitea/issues/32056
### ⚠ BREAKING
Major version change, redis provider changed to valkey.
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [X] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [X] Breaking changes are documented in the `README.md`
- [X] Helm templating unittests are added (required when changing anything in `templates` folder)
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/775
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Sean Teo <sawntoe@gmail.com>
Co-committed-by: Sean Teo <sawntoe@gmail.com>
volker.raschekandCopilot