feat(deployment)!: move strategy to deployment.strategy
changelog / changelog (push) Successful in 16s
check-and-test / check-and-test (push) Successful in 6m28s

The top-level `strategy` value only ever configured the update strategy of the Gitea Deployment, but had its own
`## @section strategy` next to chart-wide settings. Moving it into the `deployment` dict completes the
consolidation already done for `affinity`, `dnsConfig`, `nodeSelector`, `priorityClassName`, `resources`,
`schedulerName`, `tolerations` and `topologySpreadConstraints`, so everything that shapes the Deployment now
lives in one predictable place.

The parameter descriptions were rewritten while moving them. `strategy type`, `maxSurge` and `maxUnavailable`
merely repeated the key names and gave readers of the generated parameter table no information at all. They now
state the accepted values and that `rollingUpdate` is ignored for the `Recreate` strategy.

Since the `strategy` section disappeared and `clusterDomain` moved into a new `Network` section, the manually
maintained table of contents was updated accordingly, otherwise `markdownlint` fails with MD051 on the dangling
link fragments.

A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be risky: a `Recreate` strategy configured to avoid two pods writing to the same `ReadWriteOnce` volume would
fall back to `RollingUpdate` without any warning.

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

Co-authored-by: Copilot <copilot@github.com>
This commit is contained in:
2026-09-04 12:08:57 +02:00
co-authored by Copilot
parent efd6536c1a
commit 34dd14e3d8
6 changed files with 171 additions and 138 deletions
+11 -11
View File
@@ -106,6 +106,15 @@ deployment:
## @param deployment.schedulerName Use an alternate scheduler, e.g. "stork"
schedulerName: ""
## @param deployment.strategy.type Deployment strategy used to replace old pods, either `RollingUpdate` or `Recreate`.
## @param deployment.strategy.rollingUpdate.maxSurge Number or percentage of pods that may be created above the desired replica count. Only used with `RollingUpdate`.
## @param deployment.strategy.rollingUpdate.maxUnavailable Number or percentage of pods that may be unavailable during the update. Only used with `RollingUpdate`.
strategy:
type: "RollingUpdate"
rollingUpdate:
maxSurge: "100%"
maxUnavailable: 0
## @param deployment.terminationGracePeriodSeconds How long to wait until forcefully kill the pod
terminationGracePeriodSeconds: 60
@@ -239,17 +248,8 @@ namespace: ""
## @param replicaCount number of replicas for the deployment
replicaCount: 1
## @section strategy
## @param strategy.type strategy type
## @param strategy.rollingUpdate.maxSurge maxSurge
## @param strategy.rollingUpdate.maxUnavailable maxUnavailable
strategy:
type: "RollingUpdate"
rollingUpdate:
maxSurge: "100%"
maxUnavailable: 0
## @param clusterDomain cluster domain
## @section Network
## @param clusterDomain Domain of the Cluster. Domain is part of internally issued certificates.
clusterDomain: cluster.local
## @section Image