The chart-managed init containers were hardcoded inside `deployment.yaml`. Their image, environment, resources,
security context and volume mounts could not be adjusted individually, and custom init containers could only be
prepended or appended as a whole via `preExtraInitContainers`/`postExtraInitContainers`.
The init containers are now rendered from `deployment.initContainers`, an ordered list whose entries either `link` a
chart-managed init container (`initDirectories`, `initAppIni`, `initConfigureGPG`, `initConfigureGitea`) or provide a
free-form `container` definition. This allows custom containers at any position and makes the execution order
explicit. Each linked init container has its own configuration block in `values.yaml` and falls back to
`deployment.gitea.securityContext` and `initContainers.resources` when unset.
To support per-container images, `gitea.image` was split into the generic helper `gitea.image.name`, which renders an
arbitrary `image` dict instead of only `deployment.gitea.image`.
The pod annotations moved from `deployment.yaml` into the new helper `gitea.pod.annotations`. The SHA sum annotations
now also cover user-provided Secrets: their content is unknown to the chart, so the Secret is read from the cluster via
Helm's `lookup` function. Chart-managed Secrets keep using the rendered manifest, because the cluster still holds their
pre-upgrade state during rendering.
Because `lookup` requires `get` permission on Secrets and silently returns nothing during client-side rendering
(`helm template`, `--dry-run`, Argo CD without a live cluster), `addSHASumAnnotation` now defaults to `false`. The
trade-offs are documented in the README so users can make an informed decision.
BREAKING CHANGE: `preExtraInitContainers` and `postExtraInitContainers` have been removed. Add an entry with a
`container` key before or after the linked init containers in `deployment.initContainers` instead.
BREAKING CHANGE: `secrets.<secret>.addSHASumAnnotation` now defaults to `false`. Set it to `true` explicitly to keep
the rollout trigger on Secret changes.
Co-authored-by: Copilot <copilot@github.com>
The Deployment metadata inlined the annotation and label logic with nested
`if` blocks, which duplicated the fallback handling and made the empty-value
cases hard to follow. Moving the rendering into `gitea.deployment.annotations`
and `gitea.deployment.labels` keeps the manifest declarative and allows other
resources to reuse the same merge semantics later on.
The helpers are consumed through `with (include ... | fromYaml)` so that an
empty result never emits a dangling `annotations:` key. Labels always render
because `gitea.labels` is never empty, which keeps Argo CD from reporting drift.
Inside the label helper the user labels are appended with an untrimmed newline,
otherwise they would be concatenated onto the last line of `gitea.labels` and
`fromYaml` would silently return an `Error` map instead of failing the render.
The metadata attributes are additionally sorted alphabetically to follow the
chart conventions.
Unit tests now cover the previously untested `deployment.annotations` value and
assert that the base labels keep rendering despite the new `with` guard.
Co-authored-by: Copilot <copilot@github.com>
volker.raschekandCopilot