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>
3.5 KiB
3.5 KiB
Gitea Helm Chart — Copilot Instructions
Project Overview
Kubernetes Helm chart for deploying Gitea. Uses Go/Helm templating (templates/), YAML values (values.yaml), and includes sub-charts for PostgreSQL, PostgreSQL-HA, Valkey, and Valkey-cluster.
Build & Test
make readme # Regenerate README.md parameter table + lint
make unittests-helm # Run Helm unit tests (helm-unittest plugin required)
make unittests-bash # Run bash/bats script tests (requires git submodule init)
make unittests # Both of the above
Always run make readme after changing values.yaml @param annotations.
Always run make unittests-helm after changing templates or unit tests.
Conventions
values.yaml
- Use
## @param path.to.key Descriptionannotations for every user-facing value. These drive the auto-generated README parameter table. - Property ordering within a resource block:
enabled,annotations,labelsfirst, then type-specific fields. - Top-level keys are sorted alphabetically within their section group.
- Use Helm Values pattern from renovatebot. Ensure that the attributes
registry,repositoryandtagare available as part of the dictimage. For example:
image:
registry: docker.io
repository: library/busybox
tag: 0.1.0
Templates
- Helm templates live in
templates/gitea/. Helpers live intemplates/_helpers.tpl. - Use camelCase for all files and variables (e.g
httpRoute,backendTLSPolicy,gatewayAPI,statefulSet). - Use
include "gitea.fullname"for naming resources. - Use
failfor required-value validation with clear error messages referencing the full values path. - Ensure, that the attributes
annotations,labels,nameandnamespaceare alphabetically sorted. - Render all attributes, even if they are empty, to prevent drift in Argo CD. For example,
labelsmust be rendered, whileannotationsare defined asyaml:"annotations,omitempty". - Use plural for
*.tplfiles, because they may contain functions for multiple resources of the same kind (e.g._services.tplforhttpService.yamlorsshService.yaml,_backendTLSPolicies.tplforbackendTLSPolicy.yaml).
Unit Tests
- Helm unit tests live in
unittests/helm/mirroring the template structure. - Test files are YAML using the helm-unittest format.
- Each test must set all required values explicitly — do not rely on cross-test state.
- The
values.yamlfile must passyamllint. The configuration is in.yamllint. Usemake yamllintto run the linter. - The title of the unit test should clearly describe the scenario being tested. As title must be use a short sentence starting with a capital letter and ending without a period.
Commits & PRs
- Follow Conventional Commits for PR titles and commit messages (e.g.
feat:,fix:,refactor:,docs:,style:). - See
CONTRIBUTING.mdfor full PR requirements. - Explain in detail why a change is needed, not just what the change is. Include links to relevant issues, PRs, or external references.
- Add co-authors for any contributions that are not your own. Use the
Co-authored-by:trailer in the commit message.
Documentation
docs/contains topic-specific guides (e.g.gateway-api.md,ha-setup.md).README.mdparameter tables are auto-generated — never edit them manually.