bb3b59f1ee1c1b72f66fabb8c1b46ce2dd3a1bd0
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  volker.raschekandCopilot
|
bb3b59f1ee
|
test: normalize the titles of the helm unit tests
The contributor guidelines require that the title of a unit test is "a short sentence starting with a capital
letter and ending without a period". Only 30 of the 269 titles followed that rule. The remaining ones were
lowercase verb phrases ("renders a deployment"), which made the test output read inconsistently depending on
which suite was running, and made it impossible to tell a convention violation from an intentional style.
All titles are now imperative, capitalized and unquoted-safe:
renders a deployment -> Render a Deployment
should not render when gatewayAPI.enabled is false -> Skip rendering when gatewayAPI.enabled is false
skips gpg volume spec -> Skip the gpg volume spec
The bracketed prefixes of the dependency checks and of the server section suite are kept, because they group
the tests by the chart they assert on. Only the sentence behind the prefix was rewritten.
Beyond the pure capitalization three classes of titles needed real rewording:
- The titles in image-configuration.yaml named a subject instead of a scenario ("default values", "tag
override", "digest and global registry"). They now describe what is rendered.
- init_directory_structure.sh-rootless.yaml carried "it does not chown /data ...", which rendered as
"it it does not chown" in the test output.
- The "should" prefix in the Gateway API and route suites added no information once the title is a sentence.
The title of the GIT_GC_REPOS test lost its embedded double quotes. The title was previously an unquoted YAML
scalar, so the quotes were literal characters; quoting the title turned them into a parse error. The value is
unambiguous without them.
Three byte-identical tests asserting pgpool.adminPassword existed in customization-integrity-postgresql-ha.yaml
- same template, same assertion, same expected value. They were a copy-paste artifact and shared one title, so
two of them are removed. No coverage is lost, which is why the test count drops from 269 to 267.
No snapshot files are tracked and no suite uses matchSnapshot, so retitling cannot invalidate stored snapshots.
Co-authored-by: Copilot <copilot@github.com>
|
||
|
volker.raschekandCopilot
|
64c2f1a9cc
|
fix(secrets): render config and init secrets as data to prune removed keys
Both Secrets rendered their payload via `stringData`. That field is write-only: the API server decodes it into `data` and does not persist `stringData` itself. Helm's three-way merge therefore generates a deletion patch that targets `stringData`, while the live object only ever carries `data` - so a key that disappears from the rendered manifest is never pruned and survives every upgrade. Unlike the inline-config Secret fixed in #1110, the keys here are driven by the files in `scripts/init-containers/**` rather than by user values, so the bug is latent rather than acute. It still bites whenever a script is removed or renamed in the chart: the stale key stays in the Secret and keeps being mounted into the init containers. The two inline scripts of the init Secret were YAML block scalars and had to be moved into `define` blocks to be pipeable through `b64enc`. The bodies are dedented by four columns accordingly, and `trimAll "\n"` reproduces the chomping semantics of the previous `|-` scalars. Rendering was diffed against the previous revision for defaults, rootless, initPreScript, GPG, admin, LDAP, OAuth and all valkey variants - the decoded payloads are byte-identical, so no init script changes behaviour. Unit tests now read the payloads from `data.*` with `decodeBase64: true` and assert that `stringData` no longer exists, to catch a regression early. See: https://gitea.com/gitea/helm-gitea/issues/1109 See: https://gitea.com/gitea/helm-gitea/pulls/1110 Co-authored-by: Copilot <copilot@github.com> |
||
|
volker.raschekandCopilot
|
552fe8c56e
|
refactor(templates): move the templates out of the gitea subdirectory
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> |
||
|
volker.raschekandCopilot
|
229ba12744
|
feat(secrets)!: replace the gitea.admin object with secrets.admin
The admin user was the last piece of credential handling that lived outside of the `secrets` section. Worse, it was the
only credential the chart rendered as a plain environment variable value into the Deployment: unless an existing Secret
was referenced, username and password ended up in the pod spec in clear text, readable by anyone who can `get` or
`describe` the Deployment.
`gitea.admin` is therefore removed and fully replaced by `secrets.admin`:
gitea.admin.username -> secrets.admin.new.username
gitea.admin.password -> secrets.admin.new.password
gitea.admin.email -> secrets.admin.new.email
gitea.admin.passwordMode -> secrets.admin.passwordMode
gitea.admin.existingSecret -> secrets.admin.existingSecret.{enabled,secretName}
The chart now always creates a dedicated `<fullname>-admin` Secret and the Deployment consumes `GITEA_ADMIN_USERNAME`,
`GITEA_ADMIN_PASSWORD` and `GITEA_ADMIN_EMAIL` via `secretKeyRef`. This removes the clear text credentials from the pod
spec and makes the chart-managed and the externally provided case behave identically, which previously diverged.
The email address moved into the Secret as well. It used to be interpolated directly into the init script, so changing
it rewrote the init Secret, and an operator handing over admin credentials could not supply it. The key names of an
externally provided Secret are configurable via `secrets.admin.existingSecret.{emailKey,passwordKey,usernameKey}`,
because chart-defined key names cannot be assumed for Secrets managed by an external system such as a secret store.
Admin handling was previously skipped implicitly when neither an existing Secret nor a username and password were set.
This implicit behaviour is replaced by the explicit `secrets.admin.enabled` flag, so disabling it no longer requires
blanking out unrelated values.
`gitea.admin.passwordMode` validation moved from `_helpers.tpl` to `_secrets.tpl` as
`gitea.secret.admin.passwordMode` to keep all Secret related helpers in one place. `deprecation.yaml` fails the render
when `gitea.admin` is still set and points to `secrets.admin`.
New test suites cover the rendered admin Secret, the `secretKeyRef` wiring, custom key names of an existing Secret and
the password mode validation. The `secret_admin.yaml` template is registered in every suite that renders the Deployment,
as helm-unittest requires templates referenced via `$.Template.BasePath` to be listed explicitly.
BREAKING CHANGE: The `gitea.admin` object has been removed and is replaced by `secrets.admin`. Rendering fails if
`gitea.admin` is still set. Secrets referenced via `secrets.admin.existingSecret` now additionally require an `email`
key next to `username` and `password`.
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> |
||
|
Lunny Xiao
|
1baf2d0656 |
chore(deps): upgrade to 1.26 and replace environment_to_ini_call with gitea config edit-ini (#1070)
Need more time to know how to handle `expect_environment_to_ini_call` Fix #1068 Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1070 Reviewed-by: Zettat123 <39446+zettat123@noreply.gitea.com> |