2 Commits

Include renames

Author	SHA1	Message	Date
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
deepakdeore2004andtechknowlogick	e673346bb8	Support to read environment variables from file in init containers (#993) ... ### Description of the change Gitea supports providing DB and Redis/ValKey secrets via env variables, current chart requires DB and Redis/ ValKey credentials reading from k8s secret as per below values.yaml snippet. This approach requires secret to be created beforehand. ``` - name: GITEA__database__USER valueFrom: secretKeyRef: name: gitea-ha key: db_user - name: GITEA__database__PASSWD valueFrom: secretKeyRef: name: gitea-ha key: db_password ``` Other approach is to provide the credentials in values.yaml which isnt secure. A bash variable file can be created by using vault injector like this, which then can be sourced while running `config_environment.sh` in `init-app-ini` ``` GITEA__database__NAME=gitea GITEA__database__USER=gitea_user ``` Support to read env variables from file Reference: https://developer.hashicorp.com/vault/docs/deploy/kubernetes/injector/examples#environment-variable-example ### Benefits Support to read env variables from file created by vault injector for DB and redis/ valkey credentials Support to set gitea admin user and credentials via env variables from file created by vault injector ### Possible drawbacks N/A ### ⚠ BREAKING No breaking changes ### Checklist - [X] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm) --------- Co-authored-by: techknowlogick <techknowlogick@gitea.com> Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/993 Co-authored-by: deepakdeore2004 <deepakdeore2004@noreply.gitea.com> Co-committed-by: deepakdeore2004 <deepakdeore2004@noreply.gitea.com>	2026-03-12 19:12:26 +00:00