Commit Graph
2 Commits
Author SHA1 Message Date
volker.raschekandCopilot 0a237ba2c1 refactor(serviceAccount)!: group the values into existingServiceAccount and new
Helm / helm-lint (push) Successful in 13s
changelog / changelog (push) Successful in 20s
Helm / helm-unittest (push) Failing after 40s
Markdown linter / markdown-link-checker (push) Successful in 38s
Markdown linter / markdown-lint (push) Successful in 32s
The previous notation mixed two concerns in a single flat dict: `create`/`name` decided whether the chart manages the
ServiceAccount or only references an externally provided one, while the remaining keys only ever applied to a
chart-managed ServiceAccount. That made `name` ambiguous, because it either renamed the generated object or pointed to a
foreign one, and it forced the deployment to guard the reference with `or .Values.serviceAccount.create
.Values.serviceAccount.name`.

The values are now grouped the same way as `persistence`, which was restructured in dfe087c. `serviceAccount.enabled`
controls whether the pod uses a ServiceAccount at all, `serviceAccount.existingServiceAccount` references an externally
managed object and `serviceAccount.new` holds the properties of the object created by the chart. The templates follow
the established helper layout in `templates/gitea/_serviceAccounts.tpl`.

Two latent bugs are fixed along the way. The annotation helper was defined as `gitea.secret.admin.annotations`, so the
`gitea.serviceAccount.annotations` include in the template never resolved. And the duplicated name helper
`gitea.serviceAccountName` in `templates/_helpers.tpl` is removed in favour of `gitea.serviceAccount.name`.

BREAKING CHANGE:
- `serviceAccount.create` does no longer exist. Use `serviceAccount.enabled` instead. The default changed from `false`
  to `true`, so a ServiceAccount is now created unless it is explicitly disabled.
- `serviceAccount.name` does no longer exist. Use `serviceAccount.existingServiceAccount.enabled` together with
  `serviceAccount.existingServiceAccount.existingServiceAccountName` to reference an externally managed ServiceAccount.
- `serviceAccount.annotations`, `serviceAccount.labels`, `serviceAccount.automountServiceAccountToken` and
  `serviceAccount.imagePullSecrets` moved below `serviceAccount.new`.

Co-authored-by: Copilot <copilot@github.com>
2026-09-14 19:15:58 +02:00
volker.raschekandCopilot 4884dc0fe0 refactor(templates): rename template files to match rendered resource kinds
changelog / changelog (push) Successful in 19s
check-and-test / check-and-test (push) Successful in 2m59s
The files in templates/gitea/ used a mix of naming styles: lowercase concatenations
(poddisruptionbudget.yaml, serviceaccount.yaml, servicemonitor.yaml, pvc.yaml), camelCase
(httpService.yaml, sshService.yaml) and kind-suffixed names (gpg-secret.yaml, metrics-secret.yaml).
It was therefore not obvious from a file name which Kubernetes resource it renders, and the naming
contradicted the camelCase convention the Gateway API templates already follow.

Files are now named after the kind they render, with a lowercase suffix distinguishing several
resources of the same kind:

  config.yaml              -> secret_config.yaml + secret_inlineConfig.yaml
  gpg-secret.yaml          -> secret_gpg.yaml
  init.yaml                -> secret_init.yaml
  metrics-secret.yaml      -> secret_metrics.yaml
  httpService.yaml         -> service_http.yaml
  sshService.yaml          -> service_ssh.yaml
  poddisruptionbudget.yaml -> podDisruptionBudget.yaml
  pvc.yaml                 -> persistentVolumeClaim.yaml
  serviceaccount.yaml      -> serviceAccount.yaml
  servicemonitor.yaml      -> serviceMonitor.yaml

config.yaml rendered two Secrets from a single file, which forced every unit test to address them via
documentIndex. It is split so that each file renders exactly one resource.

The rendered manifests are unchanged; only file names and the references to them were touched. This
includes the checksum/config annotation in deployment.yaml and all helm unit test suites. The HA guard
assertions had to move from deployment.yaml to secret_config.yaml: Helm sorts templates in reverse
alphabetical order, so secret_config.yaml is now rendered before deployment.yaml and the fail() is
reported for that file directly instead of bubbling up through the include chain of the Deployment.

Users relying on the template paths (e.g. `helm template --show-only` or post-renderers) have to
adjust to the new file names.

Co-authored-by: Copilot <copilot@github.com>
2026-09-03 14:20:12 +02:00