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>
The contributor guidelines require that the title of a unit test is "a short sentence starting with a capital
letter and ending without a period". Only 30 of the 269 titles followed that rule. The remaining ones were
lowercase verb phrases ("renders a deployment"), which made the test output read inconsistently depending on
which suite was running, and made it impossible to tell a convention violation from an intentional style.
All titles are now imperative, capitalized and unquoted-safe:
renders a deployment -> Render a Deployment
should not render when gatewayAPI.enabled is false -> Skip rendering when gatewayAPI.enabled is false
skips gpg volume spec -> Skip the gpg volume spec
The bracketed prefixes of the dependency checks and of the server section suite are kept, because they group
the tests by the chart they assert on. Only the sentence behind the prefix was rewritten.
Beyond the pure capitalization three classes of titles needed real rewording:
- The titles in image-configuration.yaml named a subject instead of a scenario ("default values", "tag
override", "digest and global registry"). They now describe what is rendered.
- init_directory_structure.sh-rootless.yaml carried "it does not chown /data ...", which rendered as
"it it does not chown" in the test output.
- The "should" prefix in the Gateway API and route suites added no information once the title is a sentence.
The title of the GIT_GC_REPOS test lost its embedded double quotes. The title was previously an unquoted YAML
scalar, so the quotes were literal characters; quoting the title turned them into a parse error. The value is
unambiguous without them.
Three byte-identical tests asserting pgpool.adminPassword existed in customization-integrity-postgresql-ha.yaml
- same template, same assertion, same expected value. They were a copy-paste artifact and shared one title, so
two of them are removed. No coverage is lost, which is why the test count drops from 269 to 267.
No snapshot files are tracked and no suite uses matchSnapshot, so retitling cannot invalidate stored snapshots.
Co-authored-by: Copilot <copilot@github.com>
markdown-link-check derives the anchor from the raw heading text, where the underscores of the emphasis survive
slugification as `additional-_appini_-settings`. Gitea and GitHub slugify the rendered heading instead, so the
anchor really is `additional-appini-settings` and the table of contents entry was correct all along - the checker
simply could not see it.
The entry appeared with the last regeneration of the README, which is why the job started failing now even though
the heading has been around for much longer. Removing the emphasis makes both slugifiers agree without changing the
anchor, so existing deep links keep working.
Co-authored-by: Copilot <copilot@github.com>
The chart ships shell scripts into the init containers, where a quoting or exit code bug surfaces as a broken
deployment rather than as a failing test. The bats suite covers the behaviour of config_environment.sh, but not the
classes of defects a static analyser catches, so shellcheck runs alongside it now.
The action is pinned to a commit sha, as the other actions of this workflow already are. Note that the tag is named
`2.0.0` and not `v2.0.0`, so the version comment deviates from the usual `# v<version>` form.
Submodules are deliberately not checked out. The action scans the whole working directory, and bats-core alone would
contribute several hundred files that are not ours to fix.
Co-authored-by: Copilot <copilot@github.com>
The script masked the exit codes of every command substitution it ran. `local` and `export` are commands
themselves, so their own return value overwrites the one of the substitution and `set -e` never sees a failure.
This was not only cosmetic: when `gitea generate secret` failed, the init container happily continued and exported
an empty `INTERNAL_TOKEN`, `SECRET_KEY`, `JWT_SECRET` and `LFS_JWT_SECRET`. Declaration and assignment are now
separated, which lets `set -e` abort instead of writing an app.ini with empty secrets. (SC2155)
`env2ini::log` passed its argument as the format string of `printf`. Settings names and section names are read from
user supplied configuration and are logged verbatim, so a value containing a `%` directive made `printf` consume
non-existing arguments. The message is passed as data now. `%b` instead of `%s` keeps the `\n` escapes of the
existing call sites working. (SC2059)
The remaining changes quote the file name variables and add `-r` to the `read` of the `find -print0` loop, where an
unquoted path or a backslash in a mount point would have been mangled. (SC2086, SC2162)
Co-authored-by: Copilot <copilot@github.com>
`scripts/act_runner/token.sh` bootstrapped the registration token of an act runner by patching a Kubernetes Secret
with kubectl. The deployment it belonged to is long gone, and no glob picked the file up either: the chart only ships
`scripts/init-containers/config/*.sh` and `scripts/init-containers/init/*.sh`, so the script was not even part of the
packaged chart.
The label helpers `gitea.labels.actRunner` and `gitea.selectorLabels.actRunner` were orphaned the same way. The former
is referenced by no template at all and the latter only by the former, which left them as a closed loop without an
entry point.
Co-authored-by: Copilot <copilot@github.com>
Every chart-managed init container already exposes its own `volumeMounts` through the linked configuration block, so
`extraInitVolumeMounts` added a second way to express the same thing. It was also the only mount setting left outside
of `deployment`, which made the mount configuration harder to discover than it needed to be.
Worse, the name promised more than it delivered. The value was only injected into the four linked init containers and
never reached an init container added through `deployment.initContainers[].container`, even though that is exactly
what a reader would expect from a setting called "extra init volume mounts". The documented use case does not need
the fan-out either: the sample `initPreScript` copies the Postgres client certificate onto the `data` volume, so a
single mount on `deployment.initDirectories.volumeMounts` is enough and the later containers pick it up via /data.
With the value gone the `gitea.init-additional-mounts` helper has no purpose left and is removed together with its
four call sites, which now rely on the already existing `volumeMounts` block of the respective init container.
Co-authored-by: Copilot <copilot@github.com>
`extraVolumeMounts` was deprecated in 6.0.0 in favour of separate mounts for the init phase and the runtime container,
but it was never removed. It had turned into a trap: both helpers treated it as a fallback that silently disappeared as
soon as `extraInitVolumeMounts` respectively `deployment.gitea.volumeMounts` contained a single entry, so adding one
new mount could unmount everything configured through the old value. The documented successor
`extraContainerVolumeMounts` had meanwhile been removed itself, which left the deprecation note pointing at a value
that already fails the deprecation check.
Removing it makes the mount configuration explicit: `extraInitVolumeMounts` for the init containers,
`deployment.gitea.volumeMounts` for the Gitea container, and both when a volume is needed in both places.
The GPG init container used `extraVolumeMounts` directly instead of the shared helper and therefore ignored
`extraInitVolumeMounts`, unlike the three other init containers. It now uses `gitea.init-additional-mounts` as well.
Co-authored-by: Copilot <copilot@github.com>
The `preExtraInitContainers` and `postExtraInitContainers` values were removed together with the migration to
`deployment.initContainers` and are covered by a `fail` guard in templates/deprecation.yaml. Only the `## @deprecated`
annotation was left behind, pointing at values that no longer appear anywhere in this file. A reader scanning the
Init section had no way to tell that the note described a completed migration rather than a value still waiting to be
migrated.
Co-authored-by: Copilot <copilot@github.com>
The value only ever populated the `spec.ingressClassName` field of the Ingress resource, so the shortened name was a
needless deviation from the Kubernetes API. `ingress.className` carried a `DEPRECATED` marker since #679, but that
marker was a leftover: the rename to the canonical name was proposed there, rejected during review and the follow-up
commits only removed the half-merged template fallback. The marker stayed behind for a year while the value remained
the one and only way to set the Ingress class, which made the documentation actively misleading.
The deprecation guard uses `hasKey` instead of a truthiness check on purpose. The previous chart default was an empty
string, so vendored values files tend to carry `ingress.className: ""` verbatim. A truthiness check would silently
ignore those and leave users wondering why their Ingress class is no longer applied.
Co-authored-by: Copilot <copilot@github.com>
The chart shipped a `helm test` hook Pod that ran `wget` against the HTTP Service. It only proved that the
Service resolves and answers on the configured port, which the readiness probe already covers, so it carried
no information the release did not have anyway. In exchange it pulled `busybox:latest` into clusters -- an
unpinned, mutable tag in a chart that otherwise pins every image digest -- and it kept a Pod spec alive that
had to track every change to the security context and hostUsers helpers.
Removing the template also removes the `test.*` values that only existed to configure it, so the parameter
table in the README was regenerated accordingly.
A guard in `deprecation.yaml` catches leftover `test` values instead of silently ignoring them. Its message
deviates from the surrounding guards on purpose: there is no replacement value to point at, so it states that
the feature is gone rather than suggesting a migration target.
BREAKING CHANGE: `helm test <release>` no longer executes any test for this chart, and the values
`test.enabled`, `test.image.name` and `test.image.tag` have been removed. Installations that still set them
will fail with a descriptive error until the keys are dropped, unless `checkDeprecation` is set to false.
Co-authored-by: Copilot <copilot@github.com>
Both Secrets rendered their payload via `stringData`. That field is write-only: the API server decodes it into
`data` and does not persist `stringData` itself. Helm's three-way merge therefore generates a deletion patch
that targets `stringData`, while the live object only ever carries `data` - so a key that disappears from the
rendered manifest is never pruned and survives every upgrade.
Unlike the inline-config Secret fixed in #1110, the keys here are driven by the files in
`scripts/init-containers/**` rather than by user values, so the bug is latent rather than acute. It still
bites whenever a script is removed or renamed in the chart: the stale key stays in the Secret and keeps being
mounted into the init containers.
The two inline scripts of the init Secret were YAML block scalars and had to be moved into `define` blocks to
be pipeable through `b64enc`. The bodies are dedented by four columns accordingly, and `trimAll "\n"`
reproduces the chomping semantics of the previous `|-` scalars. Rendering was diffed against the previous
revision for defaults, rootless, initPreScript, GPG, admin, LDAP, OAuth and all valkey variants - the decoded
payloads are byte-identical, so no init script changes behaviour.
Unit tests now read the payloads from `data.*` with `decodeBase64: true` and assert that `stringData` no
longer exists, to catch a regression early.
See: https://gitea.com/gitea/helm-gitea/issues/1109
See: https://gitea.com/gitea/helm-gitea/pulls/1110
Co-authored-by: Copilot <copilot@github.com>
The inline-config Secret rendered its payload via `stringData`. That field is write-only: the API server
decodes it into `data` and does not persist `stringData` itself. As a result Helm's three-way merge could
never prune a key that was removed from the values, because the generated patch targets `stringData` while
the live object only has `data`. Stale sections therefore survived every upgrade and the init container kept
writing them back into `app.ini` on each start.
To prevent this class of bug from being reintroduced, document the rule explicitly: render Secret payloads as
base64 `data`, and assert Secret content in unit tests via `data.*` with `decodeBase64: true` plus a
`notExists` assertion for `stringData`.
See: https://gitea.com/gitea/helm-gitea/issues/1109
See: https://gitea.com/gitea/helm-gitea/pulls/1110
Co-authored-by: Copilot <copilot@github.com>
The inline-config Secret used `stringData`. The API server stores it as `data`, so a section removed from `gitea.config` was never pruned from the live Secret, and the init container kept writing it into `app.ini` on every start. With Gitea 28, a leftover `[webhook] ALLOWED_HOST_LIST` overrides `[security]`'s, which breaks webhooks to private hosts.
This renders the Secret as base64 `data` instead.
- `templates/secret_inlineConfig.yaml`: `stringData` → `data` (`b64enc`).
- Unit tests read `data.*` with `decodeBase64: true`; adds a regression test asserting there is no `stringData`.
Note: keys that are already stale from the `stringData` era survive the first upgrade to this version, because Helm's three-way merge never recorded them under `data`. Every removal after that is pruned.
`make unittests-helm`: 261 passed. `helm lint` and `yamllint` are clean.
Co-authored-by: perfectra1n <jonfuller2012@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1110
Co-authored-by: perfectra1n <49838+perfectra1n@noreply.gitea.com>
<!--
Before you open the request please review the following guidelines and tips to help it be more easily integrated:
- Describe the scope of your change - i.e. what the change does.
- Describe any known limitations with your change.
- Please run any tests or examples that can exercise your modified code.
Thank you for contributing! We will try to review, test and integrate the change as soon as we can.
-->
### Description of the change
<!-- Describe the scope of your change - i.e. what the change does. -->
### Benefits
<!-- What benefits will be realized by the code change? -->
### Possible drawbacks
<!-- Describe any known limitations with your change -->
### Applicable issues
<!-- Enter any applicable Issues here (You can reference an issue using #). Please remove this section if there is no referenced issue. -->
- Fixes #
### Additional information
<!-- If there's anything else that's important and relevant to your pull request, mention that information here. Please remove this section if it remains empty. -->
### ⚠ BREAKING
<!-- If there's a breaking change, please shortly describe in which way users are affected and how they can mitigate it. If there are no breakings, please remove this section. -->
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [ ] 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)
- [ ] Breaking changes are documented in the `README.md`
- [ ] Helm templating unittests are added (required when changing anything in `templates` folder)
- [ ] Bash unittests are added (required when changing anything in `scripts` folder)
- [ ] All added template resources MUST render a namespace in metadata
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1108
Co-authored-by: bircni <bircni@icloud.com>
The JSON5 syntax was not used for anything that JSON cannot express. The only comment-looking entry was already a
`description` field, which renovate evaluates itself and which therefore survives the conversion. Plain JSON is the
better default here, because it needs no dedicated parser in editors and tooling.
The converted configuration was verified against the JSON5 parser to be structurally identical to its predecessor.
Co-authored-by: Copilot <copilot@github.com>
`helm dependency build` only downloads charts from repositories that are already registered in the local repository
cache. On a fresh runner that cache is empty, so the classic repository of the valkey dependency could not be resolved:
"no repository definition for https://valkey.io/valkey-helm. Please add the missing repos via 'helm repo add'". The two
bitnami dependencies were unaffected, because OCI references do not need a repository entry.
`helm dependency update` resolves the repository URLs straight from `Chart.yaml` and therefore needs no additional
`helm repo add` step. Repeating the URL in the workflow would only invite drift, since renovate updates `Chart.yaml`
alone. All three dependencies are pinned to exact versions, so the resolution result is identical to `Chart.lock`.
This corrects 0102563, which introduced the `dependency build` step.
Co-authored-by: Copilot <copilot@github.com>
Removes the artifacts that are produced by the other targets and ignored by git, so a broken state can be reset without
remembering which directories are generated. `helm dependency build` populates `charts`, the readme generator installs
`node_modules` and packaging leaves the chart archive and its signature behind.
Co-authored-by: Copilot <copilot@github.com>
The `charts` directory is ignored by git, so a fresh checkout does not contain the postgresql, postgresql-ha and valkey
sub-charts. Locally the workflow appeared to work because `make helm/dependency-update` had populated the directory at
some earlier point.
Without the sub-charts every suite that asserts on a dependency template failed with "document index 0 is out of range"
and "template gitea/charts/postgresql/templates/primary/svc.yaml not exists or not selected in test suite". `helm lint`
was affected for the same reason.
`helm dependency build` is used instead of `helm dependency update`, because `Chart.lock` is committed and the pinned
versions should be resolved reproducibly rather than refreshed on every run.
Co-authored-by: Copilot <copilot@github.com>
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>
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>
The flat `persistence` dict mixed three concerns: whether persistence is used at all, whether the chart creates the
PersistentVolumeClaim, and how that claim is shaped. The pairs `create`/`claimName` and `enabled`/`mount` were only
meaningful in certain combinations, so an invalid configuration such as `create=true` together with a foreign
`claimName` was silently accepted. The same split into an `existingX`/`new` pair is already used for the Secrets, so
this aligns persistence with the rest of the chart.
`persistence.enabled` now only decides whether a volume is used at all. `persistence.existingPersistentVolumeClaim`
points at a claim managed outside of the chart, and everything under `persistence.new` describes the claim the chart
creates itself. Rendering and naming move into `templates/gitea/_persistentVolumeClaims.tpl` so the Deployment and the
PersistentVolumeClaim derive the claim name from a single helper instead of repeating the value lookups.
Support for `global.storageClass` is dropped. It was a chart-wide override that silently applied to the Gitea claim and
was evaluated through `tpl`, which made the effective storage class hard to predict. The storage class is now set
explicitly via `persistence.new.storageClassName`, which also matches the field name in the PersistentVolumeClaim spec.
BREAKING CHANGE: The `persistence` values were restructured and `global.storageClass` was removed.
- `persistence.create` and `persistence.mount` are gone. Set `persistence.enabled` to use a volume and
`persistence.existingPersistentVolumeClaim.enabled` to reuse a claim that is not managed by the chart.
- `persistence.claimName` moves to `persistence.existingPersistentVolumeClaim.persistentVolumeClaimName`. A claim
created by the chart is now named after `gitea.fullname` instead of the default `gitea-shared-storage`.
- `persistence.accessModes`, `annotations`, `labels`, `size` and `subPath` move into `persistence.new`.
- `persistence.volumeName` becomes `persistence.new.persistentVolumeName`.
- `persistence.storageClass` and `global.storageClass` become `persistence.new.storageClassName`.
- `persistence.enabled` now defaults to `false`.
Co-authored-by: Copilot <copilot@github.com>
The suite header was changed to the release `gitea-unittests` in the namespace `testing`, but the assertions still
expected the previous `gitea-unittest` and `gitea-debug`. That made four cases fail on the rendered resource name, the
`app.kubernetes.io/instance` label and the backend Service name.
Renovate comments had additionally been copied into the expected `app.kubernetes.io/version` and `version` label values.
They only matched by accident, because YAML strips the trailing comment from an unquoted scalar. Removing them keeps the
assertions honest about what is actually compared.
Co-authored-by: Copilot <copilot@github.com>
The `missing-dot` Makefile target enforces that every `## @param` and `## @skip` annotation ends with a dot, so that the
generated README parameter table reads consistently. 211 annotations violated that rule and made the check fail.
For the `*.image.fullOverride` parameters the dot was moved outside of the bold markup so that the sentence ends with a
dot instead of `**`.
README.md was regenerated via `make readme`.
Co-authored-by: Copilot <copilot@github.com>
The Makefile targets were renamed to a `<group>/<action>` scheme and a `missing-dot` target was added, but the Copilot
instructions still referenced the old `unittests-*` targets and a non-existent `unittests` target. Contributors and
agents following these instructions therefore ran commands that no longer exist.
Also correct the yamllint configuration file name to `.yamllint.yaml`.
Co-authored-by: Copilot <copilot@github.com>
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>
The Ingress was the last chart-managed resource that built its metadata inline. Annotations were rendered with a
`range` over the values map, which indents each entry manually and cannot be reused, and the resource had no way to
attach additional labels.
Annotations, labels and the name are now rendered by helpers in `_ingresses.tpl`, matching the pattern already used by
the other resources. This also adds `ingress.labels` so extra labels can be attached to the Ingress, and reorders the
`ingress` keys in `values.yaml` to the convention of `enabled`, `annotations` and `labels` first.
The `$httpPort` variable was assigned before the `range` over `ingress.hosts` and therefore resolved against the
wrong context once the loop rebound the dot. It has been replaced by `$.Values.service.http.port`, which reads the
value from the root context at the point of use.
Co-authored-by: Copilot <copilot@github.com>
The PodSpec `hostUsers` field has nothing to do with the OpenShift compatibility profile. It only selects whether the
pod shares the host's user namespace, which is a plain Kubernetes feature. Nesting it below `openshift` implied that it
requires OpenShift and, worse, the helper only rendered it when `openshift.enabled` evaluated to `true`, so the setting
was silently ignored on vanilla Kubernetes clusters.
`gitea.hostUsers` now reads `deployment.hostUsers` and no longer depends on the OpenShift profile. The value is only
rendered when it is an actual boolean, so the field stays omitted for `null` and the platform default applies.
BREAKING CHANGE: `openshift.hostUsers` has been removed. Configure `deployment.hostUsers` instead.
Co-authored-by: Copilot <copilot@github.com>
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>
The Deployment metadata inlined the annotation and label logic with nested
`if` blocks, which duplicated the fallback handling and made the empty-value
cases hard to follow. Moving the rendering into `gitea.deployment.annotations`
and `gitea.deployment.labels` keeps the manifest declarative and allows other
resources to reuse the same merge semantics later on.
The helpers are consumed through `with (include ... | fromYaml)` so that an
empty result never emits a dangling `annotations:` key. Labels always render
because `gitea.labels` is never empty, which keeps Argo CD from reporting drift.
Inside the label helper the user labels are appended with an untrimmed newline,
otherwise they would be concatenated onto the last line of `gitea.labels` and
`fromYaml` would silently return an `Error` map instead of failing the render.
The metadata attributes are additionally sorted alphabetically to follow the
chart conventions.
Unit tests now cover the previously untested `deployment.annotations` value and
assert that the base labels keep rendering despite the new `with` guard.
Co-authored-by: Copilot <copilot@github.com>
Both values are Deployment-scoped: `extraVolumes` is rendered into `spec.template.spec.volumes` and
`extraContainerVolumeMounts` only into the volumeMounts of the Gitea container. The `extra*` prefix said
nothing about that scope and left them sitting at the top level, far away from the pod- and container-scoped
settings that already live under `deployment` and `deployment.gitea`.
They therefore become `deployment.volumes` and `deployment.gitea.volumeMounts`, which makes the target
resource and container obvious from the values path alone and continues the consolidation started with
`deployment.gitea.env`, `deployment.gitea.image`, `deployment.gitea.resources` and the security contexts.
`extraInitVolumeMounts` stays where it is for now, because it targets the init containers rather than the
Gitea container. The deprecated `extraVolumeMounts` fallback is kept intact and now points at
`deployment.gitea.volumeMounts` in its documentation.
Both removed keys are covered by the deprecation check, because silently ignoring them would drop mounted
TLS certificates, custom themes or client certs and leave Gitea running with a broken or unexpected
configuration.
BREAKING CHANGE: `extraVolumes` and `extraContainerVolumeMounts` no longer exist. Use `deployment.volumes`
and `deployment.gitea.volumeMounts` instead. Installations that still set the old keys will fail to render
unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
`securityContext` was deprecated when the chart split it into a pod-level and a container-level value. It
only ever acted as a fallback for the runtime container: when the container-level value was empty, the
deprecated map was used instead. That fallback silently changed behaviour depending on whether an unrelated
value happened to be set, and it kept a third security-related values path alive next to
`deployment.securityContext` and `deployment.gitea.securityContext`.
With the fallback gone, `gitea.runtimeContainerSecurityContext` was identical to
`gitea.containerSecurityContext`, so the helper was dropped and the Gitea container now reuses the shared
one. A deprecation check fails the render when the removed value is still set, because silently ignoring it
would drop `runAsUser`, `runAsNonRoot` or the capability set and let the container run with weaker
restrictions than intended.
BREAKING CHANGE: `securityContext` no longer exists. Use `deployment.securityContext` for the pod-level and
`deployment.gitea.securityContext` for the container-level security context. Installations that still set
`securityContext` will fail to render unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
`podSecurityContext` and `containerSecurityContext` are both Deployment-scoped: the former is rendered into
`spec.template.spec.securityContext`, the latter into the securityContext of the Gitea container and the
chart-managed init containers. Keeping them at the top level hid that pod/container distinction behind a
naming convention and separated them from the other pod- and container-scoped settings that already live
under `deployment` and `deployment.gitea`.
`podSecurityContext` therefore becomes `deployment.securityContext` and `containerSecurityContext` becomes
`deployment.gitea.securityContext`, which makes the scope obvious from the values path alone and continues
the consolidation started with `deployment.gitea.env`, `deployment.gitea.resources` and
`deployment.gitea.image`.
The template helpers keep their argument-based signatures, because `gitea.containerSecurityContext` is also
used by the Helm test pod and is not bound to a single values path.
Both removed keys are covered by the deprecation check so that a silently dropped security context cannot
lead to containers unexpectedly running as root or without the configured capability set.
BREAKING CHANGE: `podSecurityContext` and `containerSecurityContext` no longer exist. Use
`deployment.securityContext` and `deployment.gitea.securityContext` instead. Installations that still set
the old keys will fail to render unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
The `image` values only ever configured the Gitea container itself — registry, repository, tag, digest,
pull policy and the rootless variant are all consumed by the `gitea` container and its init containers.
Keeping them at the top level suggested a chart-wide scope that never existed and separated them from the
other container-scoped settings that already live under `deployment.gitea` (`env`, `resources`).
Moving the block makes the container configuration self-contained and continues the consolidation of all
pod- and Deployment-scoped values under the `deployment` dict.
`imagePullSecrets` intentionally stays top-level, because it is a pod-level setting that also applies to
`extraContainers` and is paired with `global.imagePullSecrets`.
BREAKING CHANGE: `image` no longer exists. Use `deployment.gitea.image` instead. Values still set under
`image` are silently ignored, which would drop a pinned `tag` or `digest` and roll out the chart default
(`appVersion`) instead — review your values before upgrading.
Co-authored-by: Copilot <copilot@github.com>
The top-level `replicaCount` value only ever set the replica count of the Gitea Deployment, but was declared next
to chart-wide settings. Moving it into the `deployment` dict completes the consolidation already done for
`affinity`, `dnsConfig`, `nodeSelector`, `priorityClassName`, `resources`, `schedulerName`, `strategy`,
`tolerations` and `topologySpreadConstraints`.
The key was renamed from `replicaCount` to `replicas` at the same time. Every other key inside the `deployment`
dict mirrors the name of the corresponding Kubernetes field, so `deployment.replicas` maps one to one onto
`spec.replicas` and removes the need to remember a chart-specific alias.
A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be severe here: the release would scale back down to a single replica without any warning, and the HA guards in
the PVC and config templates, which key off the replica count, would no longer apply.
BREAKING CHANGE: `replicaCount` no longer exists. Use `deployment.replicas` instead. Installations that still set
`replicaCount` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
The top-level `strategy` value only ever configured the update strategy of the Gitea Deployment, but had its own
`## @section strategy` next to chart-wide settings. Moving it into the `deployment` dict completes the
consolidation already done for `affinity`, `dnsConfig`, `nodeSelector`, `priorityClassName`, `resources`,
`schedulerName`, `tolerations` and `topologySpreadConstraints`, so everything that shapes the Deployment now
lives in one predictable place.
The parameter descriptions were rewritten while moving them. `strategy type`, `maxSurge` and `maxUnavailable`
merely repeated the key names and gave readers of the generated parameter table no information at all. They now
state the accepted values and that `rollingUpdate` is ignored for the `Recreate` strategy.
Since the `strategy` section disappeared and `clusterDomain` moved into a new `Network` section, the manually
maintained table of contents was updated accordingly, otherwise `markdownlint` fails with MD051 on the dangling
link fragments.
A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be risky: a `Recreate` strategy configured to avoid two pods writing to the same `ReadWriteOnce` volume would
fall back to `RollingUpdate` without any warning.
BREAKING CHANGE: `strategy` no longer exists. Use `deployment.strategy` instead. Installations that still set
`strategy` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
The top-level `schedulerName` value only ever configured the pod spec of the Gitea Deployment, but was declared
next to chart-wide settings. Moving it into the `deployment` dict completes the consolidation already done for
`affinity`, `dnsConfig`, `nodeSelector`, `priorityClassName`, `resources`, `tolerations` and
`topologySpreadConstraints`, so every pod scheduling setting now lives in one predictable place.
A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be hard to debug: the pod would fall back to the `default-scheduler` without any warning, bypassing the custom
scheduler the user relies on for placement decisions such as storage locality.
BREAKING CHANGE: `schedulerName` no longer exists. Use `deployment.schedulerName` instead. Installations that
still set `schedulerName` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
The top-level `tolerations` value only ever configured the pod spec of the Gitea Deployment, but was declared
next to chart-wide settings. Moving it into the `deployment` dict completes the consolidation already done for
`affinity`, `dnsConfig`, `nodeSelector`, `priorityClassName`, `resources` and `topologySpreadConstraints`, so
every pod scheduling setting is now grouped in one predictable place instead of being scattered across the
values file.
A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be dangerous here: the tolerations would be dropped without any warning and the Gitea pod could no longer be
scheduled onto the tainted nodes it was explicitly pinned to, leaving the deployment stuck in `Pending`.
BREAKING CHANGE: `tolerations` no longer exists. Use `deployment.tolerations` instead. Installations that still
set `tolerations` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
The top-level `topologySpreadConstraints` value only ever configured the pod spec of the Gitea Deployment, yet
it lived next to chart-wide settings. This made it hard to tell which values influence the Deployment and which
apply to the chart as a whole. Moving it into the `deployment` dict continues the consolidation already done for
`affinity`, `dnsConfig`, `nodeSelector`, `priorityClassName` and `resources`, so all pod scheduling settings are
now grouped in one predictable place.
A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would
be particularly harmful here: the constraints would be dropped without any warning and all replicas could end up
scheduled on a single node or zone, defeating the availability guarantees the user configured.
BREAKING CHANGE: `topologySpreadConstraints` no longer exists. Use `deployment.topologySpreadConstraints`
instead. Installations that still set `topologySpreadConstraints` will fail unless `checkDeprecation` is set to
`false`.
Co-authored-by: Copilot <copilot@github.com>
The top-level `resources` value was applied to the Gitea container only, while its name suggested it covered the
whole pod. Kubernetes meanwhile supports pod-level resources, so a single ambiguous key can no longer express
both scopes.
Container-scoped limits and requests now live in `deployment.gitea.resources`, next to `deployment.gitea.env`,
and the new `deployment.resources` maps to the pod-level `resources` field. The pod-level block is only rendered
when set, because the field is not accepted by older API servers and would otherwise be rejected on clusters
that do not support it yet. The GOMAXPROCS derivation follows the container-scoped value and tolerates an unset
`deployment.gitea.resources`, which defaults to `null`.
The `deployment` section marker in `values.yaml` is restored as well. Without it the generated README lost its
`### deployment` heading and the manually maintained table of contents pointed at a non-existing anchor, which
made `markdownlint` fail.
BREAKING CHANGE: `resources` no longer exists. Use `deployment.gitea.resources` for container limits and
requests, or `deployment.resources` for pod-level resources. Installations that still set `resources` will fail
unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
volker.raschekandCopilot