volker.raschekandCopilot
0a237ba2c1
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>