6d68d448943e88fc9d61ba3e49f0244c24729741
11
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  volker.raschekandCopilot
|
fef4190a74
|
test: normalize the suite titles of the helm unit tests
Bash / bash-unittest (push) Successful in 14s
Bash / shellcheck (push) Successful in 20s
changelog / changelog (push) Successful in 16s
Helm / helm-lint (push) Successful in 15s
Helm / helm-unittest (push) Successful in 32s
Markdown linter / markdown-lint (push) Successful in 15s
Markdown linter / markdown-link-checker (push) Successful in 56s
The contributor guidelines never defined how a `suite` title has to look, only how an `it` title has to look. Without a rule five competing schemes grew side by side: `config template | cache config`, `deployment template (probes)`, `ServiceMonitor template (basic)`, `Test Gateway API httpRoute.yaml` and `Dependency checks | Customization integrity | valkey`. 24 of the 49 titles started with a lowercase letter, which contradicts the sentence rule that already applies to the test titles. More than cosmetics, the missing rule produced three concrete defects: - `deployment template` was used by both deployment-additional-config.yaml and extraInitContainers.yaml, and `Init template` by both init_directory_structure.sh.yaml and its rootless counterpart. `helm unittest` identifies a failing suite by its title, so a failure in either file printed the same header and the report did not say which file to open. - deployment/inline-config.yaml was titled `config template`, although it lives in the deployment directory and asserts on secret_inlineConfig.yaml. It read like a sixth member of the `config template | ...` group. - persistentVolumeClaim.yaml was titled `PVC template`, using exactly the short name the chart conventions forbid for files and keys. All suites now follow `Test <subject> <scenario>`, for example `Test deployment probes` or `Test gateway API httpRoute`. The subject is the template under test, the scenario is what distinguishes the suite from its siblings, so every title is unique and sorts next to its related suites. The `Test ` prefix of the Gateway API, ingress and route suites is kept, because it is the only part of the old schemes that already read as a sentence; the redundant `.yaml` suffix and the `tests` suffix of the storage class suite are dropped. The rule is written down in the Unit Tests section of the copilot instructions, so the next suite does not have to guess which of the five schemes was meant. Co-authored-by: Copilot <copilot@github.com> |
||
|
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
|
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
|
e8f3a058ce
|
feat(deployment)!: configurable init containers and Secret checksum lookup
The chart-managed init containers were hardcoded inside `deployment.yaml`. Their image, environment, resources, security context and volume mounts could not be adjusted individually, and custom init containers could only be prepended or appended as a whole via `preExtraInitContainers`/`postExtraInitContainers`. The init containers are now rendered from `deployment.initContainers`, an ordered list whose entries either `link` a chart-managed init container (`initDirectories`, `initAppIni`, `initConfigureGPG`, `initConfigureGitea`) or provide a free-form `container` definition. This allows custom containers at any position and makes the execution order explicit. Each linked init container has its own configuration block in `values.yaml` and falls back to `deployment.gitea.securityContext` and `initContainers.resources` when unset. To support per-container images, `gitea.image` was split into the generic helper `gitea.image.name`, which renders an arbitrary `image` dict instead of only `deployment.gitea.image`. The pod annotations moved from `deployment.yaml` into the new helper `gitea.pod.annotations`. The SHA sum annotations now also cover user-provided Secrets: their content is unknown to the chart, so the Secret is read from the cluster via Helm's `lookup` function. Chart-managed Secrets keep using the rendered manifest, because the cluster still holds their pre-upgrade state during rendering. Because `lookup` requires `get` permission on Secrets and silently returns nothing during client-side rendering (`helm template`, `--dry-run`, Argo CD without a live cluster), `addSHASumAnnotation` now defaults to `false`. The trade-offs are documented in the README so users can make an informed decision. BREAKING CHANGE: `preExtraInitContainers` and `postExtraInitContainers` have been removed. Add an entry with a `container` key before or after the linked init containers in `deployment.initContainers` instead. BREAKING CHANGE: `secrets.<secret>.addSHASumAnnotation` now defaults to `false`. Set it to `true` explicitly to keep the rollout trigger on Secret changes. 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
|
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
|
a4c6893874
|
refactor(templates)!: centralize Secret names in gitea.secret.*.name helpers
The names of the Secrets rendered by the chart were built inline in each template and, for two of them, in ad-hoc chart-wide helpers. The same name therefore existed in several places (Deployment volumes, ServiceMonitor credentials, the Secret templates themselves), which made every rename a multi-file change and allowed the references to drift apart unnoticed - the Helm unit tests render one template at a time and cannot detect a mismatching secretName. All Secret names are now defined once in templates/gitea/_secrets.tpl: gitea.secret.config.name -> <fullname>-config gitea.secret.gpg.name -> <fullname>-gpg-key (or signing.existingSecret) gitea.secret.init.name -> <fullname>-init gitea.secret.inlineConfig.name -> <fullname>-inline-config gitea.secret.metrics.name -> <fullname>-metrics gitea.gpg-key-secret-name and gitea.metrics-secret-name are removed from _helpers.tpl accordingly. A checksum/inlineConfig pod annotation is added as well. After the inline configuration had been split out of secret_config.yaml, changes to it were no longer covered by any checksum annotation and did not trigger a rollout of the Deployment. Finally the metadata attributes of the Secret templates are sorted alphabetically as required by the chart conventions. BREAKING CHANGE: two Secrets are renamed. The config Secret changes from <fullname> to <fullname>-config and the metrics Secret from <fullname>-metrics-secret to <fullname>-metrics. Helm replaces both on upgrade; references to them from outside the chart have to be adjusted. 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> |
||
|
volker.raschek
|
10ad0f7743
|
style: adapt indentation of extraInitContainer tests | ||
|
kostovicmb
|
4cfcbd729f
|
feat(deployment): support further initContainers
The following patch intoduce the dictionaries pre and postExtraInitContainers. The dictionaries can be used to specify further initContainers before and after the gitea initializing process. For example: ```yaml postExtraInitContainers: - name: foo image: docker.io/library/busybox:latest preExtraInitContainers: - name: bar image: docker.io/library/busybox:latest ``` |