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>
The `image` values only ever configured the Gitea container itself — registry, repository, tag, digest,
pull policy and the rootless variant are all consumed by the `gitea` container and its init containers.
Keeping them at the top level suggested a chart-wide scope that never existed and separated them from the
other container-scoped settings that already live under `deployment.gitea` (`env`, `resources`).
Moving the block makes the container configuration self-contained and continues the consolidation of all
pod- and Deployment-scoped values under the `deployment` dict.
`imagePullSecrets` intentionally stays top-level, because it is a pod-level setting that also applies to
`extraContainers` and is paired with `global.imagePullSecrets`.
BREAKING CHANGE: `image` no longer exists. Use `deployment.gitea.image` instead. Values still set under
`image` are silently ignored, which would drop a pinned `tag` or `digest` and roll out the chart default
(`appVersion`) instead — review your values before upgrading.
Co-authored-by: Copilot <copilot@github.com>
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>
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>
### Description of the change
This is a preparation for #724 (bash script testing) which would be too complex to review if done there. I haven't changed the script contents.
### Benefits
Better IDE support, possibility for shell checks, tests.
### Possible drawbacks
-
### Additional information
I only extracted files that are native bash scripts. There are others, being a mix of Helm templating and shell scripts. Those scripts must be cleared first before extracting them as well.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/751
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
volker.raschekandCopilot