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>
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>
The top-level `schedulerName` value only ever configured the pod spec 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`, `tolerations` and
`topologySpreadConstraints`, so every pod scheduling setting now lives in one predictable place.
A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be hard to debug: the pod would fall back to the `default-scheduler` without any warning, bypassing the custom
scheduler the user relies on for placement decisions such as storage locality.
BREAKING CHANGE: `schedulerName` no longer exists. Use `deployment.schedulerName` instead. Installations that
still set `schedulerName` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
The top-level `tolerations` value only ever configured the pod spec 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` and `topologySpreadConstraints`, so
every pod scheduling setting is now grouped in one predictable place instead of being scattered across the
values file.
A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be dangerous here: the tolerations would be dropped without any warning and the Gitea pod could no longer be
scheduled onto the tainted nodes it was explicitly pinned to, leaving the deployment stuck in `Pending`.
BREAKING CHANGE: `tolerations` no longer exists. Use `deployment.tolerations` instead. Installations that still
set `tolerations` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
The top-level `topologySpreadConstraints` value only ever configured the pod spec of the Gitea Deployment, yet
it lived next to chart-wide settings. This made it hard to tell which values influence the Deployment and which
apply to the chart as a whole. Moving it into the `deployment` dict continues the consolidation already done for
`affinity`, `dnsConfig`, `nodeSelector`, `priorityClassName` and `resources`, so all pod scheduling settings are
now grouped in one predictable place.
A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be particularly harmful here: the constraints would be dropped without any warning and all replicas could end up
scheduled on a single node or zone, defeating the availability guarantees the user configured.
BREAKING CHANGE: `topologySpreadConstraints` no longer exists. Use `deployment.topologySpreadConstraints`
instead. Installations that still set `topologySpreadConstraints` will fail unless `checkDeprecation` is set to
`false`.
Co-authored-by: Copilot <copilot@github.com>
The top-level `resources` value was applied to the Gitea container only, while its name suggested it covered the
whole pod. Kubernetes meanwhile supports pod-level resources, so a single ambiguous key can no longer express
both scopes.
Container-scoped limits and requests now live in `deployment.gitea.resources`, next to `deployment.gitea.env`,
and the new `deployment.resources` maps to the pod-level `resources` field. The pod-level block is only rendered
when set, because the field is not accepted by older API servers and would otherwise be rejected on clusters
that do not support it yet. The GOMAXPROCS derivation follows the container-scoped value and tolerates an unset
`deployment.gitea.resources`, which defaults to `null`.
The `deployment` section marker in `values.yaml` is restored as well. Without it the generated README lost its
`### deployment` heading and the manually maintained table of contents pointed at a non-existing anchor, which
made `markdownlint` fail.
BREAKING CHANGE: `resources` no longer exists. Use `deployment.gitea.resources` for container limits and
requests, or `deployment.resources` for pod-level resources. Installations that still set `resources` will fail
unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
`nodeSelector` was a top-level value although it exclusively configures the pod spec of the Gitea Deployment.
With `affinity`, `dnsConfig` and the container environment already moved into the `deployment` dict, keeping
`nodeSelector` at the root level leaves the scheduling configuration split across two places.
Moving it into the `deployment` dict continues the consolidation of Deployment-scoped values and keeps
`nodeSelector` next to the closely related `affinity` setting. The `@param` annotations are grouped with the
values they document so the generated README table stays in sync with the structure.
A deprecation check is added so that existing installations fail fast with an actionable error message. Without
it, the node selection would be dropped silently and pods could be scheduled on nodes that do not meet the
intended requirements.
BREAKING CHANGE: `nodeSelector` no longer exists. Use `deployment.nodeSelector` instead. Installations that
still set `nodeSelector` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
`dnsConfig` was a top-level value although it exclusively configures the pod spec of the Gitea Deployment. With
`affinity` and `env` already moved into the `deployment` dict, keeping `dnsConfig` at the root level leaves the
Deployment configuration split across two places and makes it harder to see which values end up in the rendered
pod spec.
Moving it into the `deployment` dict continues the consolidation of Deployment-scoped values and keeps the
values structure predictable for the remaining pod-level settings.
A deprecation check is added so that existing installations fail fast with an actionable error message. Without
it, a custom DNS configuration would be dropped silently, which typically surfaces much later as unexplained
name resolution failures inside the Gitea pod.
BREAKING CHANGE: `dnsConfig` no longer exists. Use `deployment.dnsConfig` instead. Installations that still set
`dnsConfig` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
The `deployment` dict mixes values that apply to the Deployment object itself (`annotations`, `labels`,
`affinity`, `terminationGracePeriodSeconds`) with values that apply to a single container. `deployment.env` was
the only container-scoped key, which made it unclear which container it targets once further containers get
their own configuration.
Grouping container-scoped values under `deployment.gitea` establishes a per-container namespace and leaves room
for sibling sections without another breaking rename later. The value ordering in `values.yaml` is aligned with
the chart conventions (`enabled`, `annotations`, `labels` first).
`deployment.enabled` is introduced and wired up in the template so the Deployment can be skipped entirely. This
allows the chart to be used for rendering only the surrounding resources, e.g. when the workload itself is
managed elsewhere.
A deprecation check is added so that existing installations fail fast with an actionable error message instead
of silently dropping their environment variables, which would otherwise surface as hard-to-debug runtime
misconfiguration.
Unit tests cover the disabled Deployment, the propagation of `deployment.gitea.env` into all init containers and
the Gitea container, and the deprecation checks for `affinity` and `deployment.env`.
BREAKING CHANGE: `deployment.env` no longer exists. Use `deployment.gitea.env` instead. Installations that
still set `deployment.env` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
Moving `affinity` into the `deployment` dict groups it with the other Deployment-specific values and prepares a
consistent structure for further migrations of pod-level settings.
A deprecation check is added so that existing installations fail fast with an actionable error message instead of
silently dropping the affinity rules, which would otherwise lead to pods being scheduled on unintended nodes.
BREAKING CHANGE: `affinity` no longer exists. Use `deployment.affinity` instead. Installations that still set
`affinity` will fail unless `checkDeprecation` is set to `false`.
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 `signing` object was the last Secret-related configuration living outside of the `secrets` section introduced in the
previous commit. Keeping it separate meant that the GPG key Secret was the only one without configurable annotations,
labels and a proper `existingSecret` reference, and users had to learn two different conventions for the same concept.
`signing` is therefore removed and fully replaced by `secrets.gpg`:
signing.enabled -> secrets.gpg.enabled
signing.gpgHome -> secrets.gpg.new.gpgHome
signing.privateKey -> secrets.gpg.new.privateKey
signing.existingSecret -> secrets.gpg.existingSecret.{enabled,secretName}
`gpgHome` is now stored as a key inside the GPG key Secret and consumed via `secretKeyRef` instead of being rendered as
a plain environment variable value. This keeps the whole GPG configuration in a single object, so an operator can hand
over one Secret that fully describes the signing setup instead of splitting it across values and Secret data. The key
names of an externally provided Secret are configurable via `secrets.gpg.existingSecret.gpgHomeKey` and
`secrets.gpg.existingSecret.privateKeyKey`, because chart-defined key names cannot be assumed for Secrets that are
managed by an external system such as an operator or a secret store.
To avoid silently ignoring a now unknown value, `deprecation.yaml` fails the render when `signing` is still set and
points to `secrets.gpg`. As with the other deprecation guards it can be bypassed via `checkDeprecation: false`.
The unit tests are migrated accordingly and the `GNUPGHOME` assertions now verify the `secretKeyRef` shape. Two new
cases cover custom `gpgHomeKey` and `privateKeyKey` values of an existing Secret.
The README gains a `To 13.0.0` upgrade section documenting this change together with the `secrets.*` block and the
Secret renames of the preceding commits.
BREAKING CHANGE: The `signing` object has been removed and is replaced by `secrets.gpg`. Rendering fails if `signing`
is still set. Secrets referenced via `secrets.gpg.existingSecret` now additionally require a `gpgHome` key next to
`privateKey`.
Co-authored-by: Copilot <copilot@github.com>
With release 5.0.0 there are so many deprecations and breaking changes
that it is probably a good way to assist the users with values migration
before breaking their environments.
This adds another template file that doesn't render anything but ensures
the removal of dropped or deprecated settings from customized values
files.
For when it is necessary, this check can be disabled via new setting
`checkDeprecation`.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/269
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: wxiaoguang <wxiaoguang@noreply.gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
volker.raschekandCopilot