volker.raschek/helm-gitea
1
0
Fork 0
Code Issues 3 Pull Requests 7 Actions Packages Projects Releases Wiki Activity

feat(deployment)!: move replicaCount to deployment.replicas
changelog / changelog (push) Successful in 21s
Details
check-and-test / check-and-test (push) Successful in 6m34s
Details

Browse Source 
The top-level `replicaCount` value only ever set the replica count of the Gitea Deployment, but was declared next
to chart-wide settings. Moving it into the `deployment` dict completes the consolidation already done for
`affinity`, `dnsConfig`, `nodeSelector`, `priorityClassName`, `resources`, `schedulerName`, `strategy`,
`tolerations` and `topologySpreadConstraints`.

The key was renamed from `replicaCount` to `replicas` at the same time. Every other key inside the `deployment`
dict mirrors the name of the corresponding Kubernetes field, so `deployment.replicas` maps one to one onto
`spec.replicas` and removes the need to remember a chart-specific alias.

A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be severe here: the release would scale back down to a single replica without any warning, and the HA guards in
the PVC and config templates, which key off the replica count, would no longer apply.

BREAKING CHANGE: `replicaCount` no longer exists. Use `deployment.replicas` instead. Installations that still set
`replicaCount` will fail unless `checkDeprecation` is set to `false`.

Co-authored-by: Copilot <copilot@github.com>
This commit is contained in:
volker.raschek
2026-09-04 12:16:54 +02:00
co-authored by Copilot
parent 34dd14e3d8
commit f385d22b56
9 changed files with 29 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ha-setup.md
+2 -2
View File
@@ -14,7 +14,7 @@ They might cost a bit more than using a self-hosted k8s variant but are usually
Also they can be centrally managed and are not linked to the Gitea helm chart or namespace.
Please consider using external services before you start with your Gitea HA setup, it will make your life (and the life of the Gitea maintainers) easier.
This helm chart tries to help as much as possible to simplify and assert the provisioning of a HA-ready Gitea instance by implementing smart conditionals if `replicaCount` is set to a value > 1.
This helm chart tries to help as much as possible to simplify and assert the provisioning of a HA-ready Gitea instance by implementing smart conditionals if `deployment.replicas` is set to a value > 1.
Nevertheless, we cannot guarantee for every possible combination of Gitea settings to work together perfectly in a HA setup.
As a general advice, we recommend to have a test environment aside on which to test possible changes/upgrades before applying these to a production installation.
@@ -175,4 +175,4 @@ gitea:
- Currently Cron jobs are run on all replicas as no leader election is implemented.
See [https://github.com/go-gitea/gitea/issues/13791](https://github.com/go-gitea/gitea/issues/13791) for a discussion and possible solution.
- Running with multiple replicas slows down Gitea a bit, i.e. page loading time increases.
- Running with multiple replicas slows down Gitea a bit, i.e. page loading time increases.