3 Commits

Include renames

Author	SHA1	Message	Date
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>	2026-09-03 20:43:53 +02:00
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>	2026-09-03 14:20:12 +02:00
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>	2026-05-11 16:50:15 +00:00