3 Commits

Include renames

Author	SHA1	Message	Date
volker.raschekandCopilot	fef4190a74	test: normalize the suite titles of the helm unit tests ... 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>	2026-10-03 21:21:46 +02:00
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>	2026-09-14 20:28:17 +02:00
volker.raschekandCopilot	0a237ba2c1	refactor(serviceAccount)!: group the values into existingServiceAccount and new ... 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>	2026-09-14 19:15:58 +02:00