2 Commits
Author SHA1 Message Date
volker.raschekandCopilot 552fe8c56e refactor(templates): move the templates out of the gitea subdirectory
Helm / helm-lint (push) Successful in 9s
changelog / changelog (push) Successful in 29s
Helm / helm-unittest (push) Failing after 21s
Markdown linter / markdown-lint (push) Successful in 17s
Markdown linter / markdown-link-checker (push) Successful in 56s
The `templates/gitea` subdirectory did not group anything meaningful, since every template of this chart belongs to
Gitea. It only duplicated the chart name in every path and forced the unit tests to spell out
`templates/gitea/<name>.yaml`, while `_helpers.tpl` and `NOTES.txt` already lived directly in `templates`.

All templates now live in `templates`, which matches the layout of the bundled sub-charts and the Helm defaults.

The checksum helper in `templates/_secrets.tpl` built its include path from `$root.Template.BasePath` and therefore
carried the subdirectory in a `printf` format string instead of a literal path. Without adjusting it the chart failed to
render with "no template gitea/templates/gitea/secret_config.yaml associated with template gotpl".

Co-authored-by: Copilot <copilot@github.com>
2026-09-14 20:28:17 +02:00
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