`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>
volker.raschekandCopilot