e17a4e7a7b2f5e2a626719fa084c53854ddb454b
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  volker.raschekandCopilot
|
3535611d4d
|
feat(secrets)!: replace the signing object with secrets.gpg
The `signing` object was the last Secret-related configuration living outside of the `secrets` section introduced in the
previous commit. Keeping it separate meant that the GPG key Secret was the only one without configurable annotations,
labels and a proper `existingSecret` reference, and users had to learn two different conventions for the same concept.
`signing` is therefore removed and fully replaced by `secrets.gpg`:
signing.enabled -> secrets.gpg.enabled
signing.gpgHome -> secrets.gpg.new.gpgHome
signing.privateKey -> secrets.gpg.new.privateKey
signing.existingSecret -> secrets.gpg.existingSecret.{enabled,secretName}
`gpgHome` is now stored as a key inside the GPG key Secret and consumed via `secretKeyRef` instead of being rendered as
a plain environment variable value. This keeps the whole GPG configuration in a single object, so an operator can hand
over one Secret that fully describes the signing setup instead of splitting it across values and Secret data. The key
names of an externally provided Secret are configurable via `secrets.gpg.existingSecret.gpgHomeKey` and
`secrets.gpg.existingSecret.privateKeyKey`, because chart-defined key names cannot be assumed for Secrets that are
managed by an external system such as an operator or a secret store.
To avoid silently ignoring a now unknown value, `deprecation.yaml` fails the render when `signing` is still set and
points to `secrets.gpg`. As with the other deprecation guards it can be bypassed via `checkDeprecation: false`.
The unit tests are migrated accordingly and the `GNUPGHOME` assertions now verify the `secretKeyRef` shape. Two new
cases cover custom `gpgHomeKey` and `privateKeyKey` values of an existing Secret.
The README gains a `To 13.0.0` upgrade section documenting this change together with the `secrets.*` block and the
Secret renames of the preceding commits.
BREAKING CHANGE: The `signing` object has been removed and is replaced by `secrets.gpg`. Rendering fails if `signing`
is still set. Secrets referenced via `secrets.gpg.existingSecret` now additionally require a `gpgHome` key next to
`privateKey`.
Co-authored-by: Copilot <copilot@github.com>
|
||
|
volker.raschekandCopilot
|
4d82f17ce6
|
feat(secrets): make every Secret configurable via a secrets.* block
Until now the Secrets rendered by this chart were not configurable at all. Their labels were fixed to the chart defaults, they could not carry annotations, and there was no way to hand in a Secret that is managed outside of the chart - except for the GPG key, which had its own special case via `signing.existingSecret`. Users who manage their secrets with an external operator (e.g. External Secrets, Sealed Secrets) or who need annotations for tooling such as Reloader or Kyverno had no option but to fork the chart. A `secrets` section is introduced with one entry per Secret (config, gpg, init, inlineConfig, metrics), each offering: addSHASumAnnotation add a checksum annotation to the pod template (default: true) existingSecret.enabled reference a Secret that is not managed by this chart existingSecret.secretName name of that Secret new.annotations annotations for the Secret created by the chart new.labels additional labels for the Secret created by the chart The `new` sub-key keeps the properties of a chart-managed Secret clearly separated from the properties of a referenced one, so it is obvious which settings are ignored once `existingSecret` is enabled. `secretName` rather than `name` mirrors the field the value ends up in, the `secretName` of a pod volume. The `gitea.secret.*.name` helpers resolve to the user-provided name when `existingSecret` is enabled, which means the Deployment volumes and the ServiceMonitor credentials pick it up without further changes. Enabling `existingSecret` without a name fails the render with a message naming the full values path, because Helm would otherwise silently create a Secret under the referenced name and overwrite it. Only two of the five Secrets had a checksum annotation before, so changes to the init scripts, the GPG key or the metrics token did not trigger a rollout. Annotations for all five are now rendered, each gated by `addSHASumAnnotation` and skipped for Secrets the chart does not manage. Two side effects had to be preserved when a Secret is no longer rendered: - secret_config.yaml carries the HA assertions (RWX access mode, issue/repo indexer, mutually exclusive PostgreSQL dependencies) inside its `assertions` field. They are extracted into `gitea.config.assertions` and evaluated before the guard, otherwise providing an own config Secret would silently disable chart-wide validation. - secret_inlineConfig.yaml populates `.Values.gitea.config` as a side effect of `gitea.inline_configuration`. Without evaluating it, even NOTES.txt fails on `.Values.gitea.config.cache`. The include therefore runs independently of the guard as well. `signing.existingSecret` keeps working; `secrets.gpg.existingSecret` takes precedence over it. The error message raised for an enabled but unconfigured signing setup now lists all three options. Test suites rendering the Deployment have to declare the Secret templates it checksums, hence the added `templates:` entries. unittests/helm/deployment/extraInitContainers.yaml set `signing.enabled` without a key or an existing Secret - a combination that fails a real `helm install` and only went unnoticed because the Deployment never rendered secret_gpg.yaml before. Co-authored-by: Copilot <copilot@github.com> |
||
|
volker.raschekandCopilot
|
4884dc0fe0
|
refactor(templates): rename template files to match rendered resource kinds
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> |
||
|
justusbunsi
|
4691b63f7a |
Move Helm unittests into subfolder (#750)
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/750 Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com> |