4 Commits

Include renames

Author	SHA1	Message	Date
volker.raschekandCopilot	e48610c0fc	refactor(ingress)!: skip the Ingress when the HTTP Service is disabled ... An Ingress that points at a Service which the chart does not render is broken by definition: the backend reference cannot resolve and the ingress controller reports the rule as unavailable. The render condition therefore now also requires `service.http.enabled` and lives in the new `gitea.ingress.enabled` helper, so the same rule can be reused by other templates instead of being duplicated. The namespace is taken from `.Release.Namespace` again. The `namespace` value is not a documented chart parameter, and letting a single resource opt out of the release namespace breaks `helm uninstall` and Argo CD pruning, because neither tracks objects outside the release namespace. The `ingress.className` default changes from an empty string to `nginx`. An empty class makes the cluster fall back to the default IngressClass, which silently produces a different result per cluster; naming the controller the chart is tested against makes the rendered output predictable. The scattered ingress suites are consolidated into a single `unittests/helm/ingress/ingress.yaml` that pins the release name, namespace and appVersion, as required by the testing conventions, and covers the enable/disable matrix, annotations, labels, TLS and a custom HTTP port. BREAKING CHANGE: The Ingress is no longer rendered when `service.http.enabled` is `false`. `ingress.className` now defaults to `nginx` instead of the cluster's default IngressClass. The undocumented `namespace` value no longer applies to the Ingress. Co-authored-by: Copilot <copilot@github.com>	2026-09-13 20:17:17 +02:00
volker.raschek	cc99cada4d	fix(copilot): adapt file name pattern	2026-09-13 19:13:20 +02:00
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>	2026-09-13 19:11:28 +02:00
Todd Marimon	7747a001f7	feat: add Gateway API support (#1073) ... Add full Gateway API support for exposing Gitea via HTTPRoute, TCPRoute, BackendTLSPolicy, and ClientSettingsPolicy resources. New templates: - `httpRoute.yaml` — renders an HTTPRoute with configurable parentRefs, hostnames, and rules (defaults to PathPrefix `/`) - `tcpRoute.yaml` — renders a TCPRoute for SSH traffic - `backendTLSPolicy.yaml` — renders a BackendTLSPolicy for encrypted backend connections with required validation config - `clientSettingsPolicy.yaml` — renders an NGINX Gateway Fabric ClientSettingsPolicy to raise the request body size limit Infrastructure: - `gatewayAPI.enabled` global toggle gates all resources - Resources grouped under `gatewayAPI.core.*` and `gatewayAPI.nginx.*` - Helper templates extracted into dedicated `_*.tpl` files - Service name helpers (`gitea.service.http.name`, `gitea.service.ssh.name`) extracted into `_services.tpl`; service templates renamed to camelCase - `ROOT_URL`, `DOMAIN`, and `SSH_DOMAIN` auto-resolve from `httpRoute.hostnames[0]`; `httpRoute.tls` switches to `https` Documentation: - New `docs/gateway-api.md` with topology examples, BackendTLSPolicy setup, sectionName guidance, SSH considerations, and NGINX body size limit configuration - `.github/copilot-instructions.md` with project conventions - README parameter table auto-generated via `make readme` Tests: - Helm unit tests for all four new resource templates - Config tests for hostname/TLS resolution from Gateway API values Co-authored-by: Todd Marimon <toddmarimon@gmail.com>	2026-07-19 16:25:28 +00:00