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>
`nodeSelector` was a top-level value although it exclusively configures the pod spec of the Gitea Deployment.
With `affinity`, `dnsConfig` and the container environment already moved into the `deployment` dict, keeping
`nodeSelector` at the root level leaves the scheduling configuration split across two places.
Moving it into the `deployment` dict continues the consolidation of Deployment-scoped values and keeps
`nodeSelector` next to the closely related `affinity` setting. The `@param` annotations are grouped with the
values they document so the generated README table stays in sync with the structure.
A deprecation check is added so that existing installations fail fast with an actionable error message. Without
it, the node selection would be dropped silently and pods could be scheduled on nodes that do not meet the
intended requirements.
BREAKING CHANGE: `nodeSelector` no longer exists. Use `deployment.nodeSelector` instead. Installations that
still set `nodeSelector` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
`dnsConfig` was a top-level value although it exclusively configures the pod spec of the Gitea Deployment. With
`affinity` and `env` already moved into the `deployment` dict, keeping `dnsConfig` at the root level leaves the
Deployment configuration split across two places and makes it harder to see which values end up in the rendered
pod spec.
Moving it into the `deployment` dict continues the consolidation of Deployment-scoped values and keeps the
values structure predictable for the remaining pod-level settings.
A deprecation check is added so that existing installations fail fast with an actionable error message. Without
it, a custom DNS configuration would be dropped silently, which typically surfaces much later as unexplained
name resolution failures inside the Gitea pod.
BREAKING CHANGE: `dnsConfig` no longer exists. Use `deployment.dnsConfig` instead. Installations that still set
`dnsConfig` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
The `deployment` dict mixes values that apply to the Deployment object itself (`annotations`, `labels`,
`affinity`, `terminationGracePeriodSeconds`) with values that apply to a single container. `deployment.env` was
the only container-scoped key, which made it unclear which container it targets once further containers get
their own configuration.
Grouping container-scoped values under `deployment.gitea` establishes a per-container namespace and leaves room
for sibling sections without another breaking rename later. The value ordering in `values.yaml` is aligned with
the chart conventions (`enabled`, `annotations`, `labels` first).
`deployment.enabled` is introduced and wired up in the template so the Deployment can be skipped entirely. This
allows the chart to be used for rendering only the surrounding resources, e.g. when the workload itself is
managed elsewhere.
A deprecation check is added so that existing installations fail fast with an actionable error message instead
of silently dropping their environment variables, which would otherwise surface as hard-to-debug runtime
misconfiguration.
Unit tests cover the disabled Deployment, the propagation of `deployment.gitea.env` into all init containers and
the Gitea container, and the deprecation checks for `affinity` and `deployment.env`.
BREAKING CHANGE: `deployment.env` no longer exists. Use `deployment.gitea.env` instead. Installations that
still set `deployment.env` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
Moving `affinity` into the `deployment` dict groups it with the other Deployment-specific values and prepares a
consistent structure for further migrations of pod-level settings.
A deprecation check is added so that existing installations fail fast with an actionable error message instead of
silently dropping the affinity rules, which would otherwise lead to pods being scheduled on unintended nodes.
BREAKING CHANGE: `affinity` no longer exists. Use `deployment.affinity` instead. Installations that still set
`affinity` will fail unless `checkDeprecation` is set to `false`.
Co-authored-by: Copilot <copilot@github.com>
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>
The `signing` object was the last Secret-related configuration living outside of the `secrets` section introduced in the
previous commit. Keeping it separate meant that the GPG key Secret was the only one without configurable annotations,
labels and a proper `existingSecret` reference, and users had to learn two different conventions for the same concept.
`signing` is therefore removed and fully replaced by `secrets.gpg`:
signing.enabled -> secrets.gpg.enabled
signing.gpgHome -> secrets.gpg.new.gpgHome
signing.privateKey -> secrets.gpg.new.privateKey
signing.existingSecret -> secrets.gpg.existingSecret.{enabled,secretName}
`gpgHome` is now stored as a key inside the GPG key Secret and consumed via `secretKeyRef` instead of being rendered as
a plain environment variable value. This keeps the whole GPG configuration in a single object, so an operator can hand
over one Secret that fully describes the signing setup instead of splitting it across values and Secret data. The key
names of an externally provided Secret are configurable via `secrets.gpg.existingSecret.gpgHomeKey` and
`secrets.gpg.existingSecret.privateKeyKey`, because chart-defined key names cannot be assumed for Secrets that are
managed by an external system such as an operator or a secret store.
To avoid silently ignoring a now unknown value, `deprecation.yaml` fails the render when `signing` is still set and
points to `secrets.gpg`. As with the other deprecation guards it can be bypassed via `checkDeprecation: false`.
The unit tests are migrated accordingly and the `GNUPGHOME` assertions now verify the `secretKeyRef` shape. Two new
cases cover custom `gpgHomeKey` and `privateKeyKey` values of an existing Secret.
The README gains a `To 13.0.0` upgrade section documenting this change together with the `secrets.*` block and the
Secret renames of the preceding commits.
BREAKING CHANGE: The `signing` object has been removed and is replaced by `secrets.gpg`. Rendering fails if `signing`
is still set. Secrets referenced via `secrets.gpg.existingSecret` now additionally require a `gpgHome` key next to
`privateKey`.
Co-authored-by: Copilot <copilot@github.com>
Until now the Secrets rendered by this chart were not configurable at all. Their labels were fixed
to the chart defaults, they could not carry annotations, and there was no way to hand in a Secret
that is managed outside of the chart - except for the GPG key, which had its own special case via
`signing.existingSecret`. Users who manage their secrets with an external operator (e.g. External
Secrets, Sealed Secrets) or who need annotations for tooling such as Reloader or Kyverno had no
option but to fork the chart.
A `secrets` section is introduced with one entry per Secret (config, gpg, init, inlineConfig,
metrics), each offering:
addSHASumAnnotation add a checksum annotation to the pod template (default: true)
existingSecret.enabled reference a Secret that is not managed by this chart
existingSecret.secretName name of that Secret
new.annotations annotations for the Secret created by the chart
new.labels additional labels for the Secret created by the chart
The `new` sub-key keeps the properties of a chart-managed Secret clearly separated from the
properties of a referenced one, so it is obvious which settings are ignored once `existingSecret` is
enabled. `secretName` rather than `name` mirrors the field the value ends up in, the `secretName` of
a pod volume.
The `gitea.secret.*.name` helpers resolve to the user-provided name when `existingSecret` is
enabled, which means the Deployment volumes and the ServiceMonitor credentials pick it up without
further changes. Enabling `existingSecret` without a name fails the render with a message naming the
full values path, because Helm would otherwise silently create a Secret under the referenced name and
overwrite it.
Only two of the five Secrets had a checksum annotation before, so changes to the init scripts, the
GPG key or the metrics token did not trigger a rollout. Annotations for all five are now rendered,
each gated by `addSHASumAnnotation` and skipped for Secrets the chart does not manage.
Two side effects had to be preserved when a Secret is no longer rendered:
- secret_config.yaml carries the HA assertions (RWX access mode, issue/repo indexer, mutually
exclusive PostgreSQL dependencies) inside its `assertions` field. They are extracted into
`gitea.config.assertions` and evaluated before the guard, otherwise providing an own config Secret
would silently disable chart-wide validation.
- secret_inlineConfig.yaml populates `.Values.gitea.config` as a side effect of
`gitea.inline_configuration`. Without evaluating it, even NOTES.txt fails on
`.Values.gitea.config.cache`. The include therefore runs independently of the guard as well.
`signing.existingSecret` keeps working; `secrets.gpg.existingSecret` takes precedence over it. The
error message raised for an enabled but unconfigured signing setup now lists all three options.
Test suites rendering the Deployment have to declare the Secret templates it checksums, hence the
added `templates:` entries. unittests/helm/deployment/extraInitContainers.yaml set `signing.enabled`
without a key or an existing Secret - a combination that fails a real `helm install` and only went
unnoticed because the Deployment never rendered secret_gpg.yaml before.
Co-authored-by: Copilot <copilot@github.com>
The names of the Secrets rendered by the chart were built inline in each template and, for two of
them, in ad-hoc chart-wide helpers. The same name therefore existed in several places (Deployment
volumes, ServiceMonitor credentials, the Secret templates themselves), which made every rename a
multi-file change and allowed the references to drift apart unnoticed - the Helm unit tests render
one template at a time and cannot detect a mismatching secretName.
All Secret names are now defined once in templates/gitea/_secrets.tpl:
gitea.secret.config.name -> <fullname>-config
gitea.secret.gpg.name -> <fullname>-gpg-key (or signing.existingSecret)
gitea.secret.init.name -> <fullname>-init
gitea.secret.inlineConfig.name -> <fullname>-inline-config
gitea.secret.metrics.name -> <fullname>-metrics
gitea.gpg-key-secret-name and gitea.metrics-secret-name are removed from _helpers.tpl accordingly.
A checksum/inlineConfig pod annotation is added as well. After the inline configuration had been
split out of secret_config.yaml, changes to it were no longer covered by any checksum annotation and
did not trigger a rollout of the Deployment.
Finally the metadata attributes of the Secret templates are sorted alphabetically as required by the
chart conventions.
BREAKING CHANGE: two Secrets are renamed. The config Secret changes from <fullname> to
<fullname>-config and the metrics Secret from <fullname>-metrics-secret to <fullname>-metrics. Helm
replaces both on upgrade; references to them from outside the chart have to be adjusted.
Co-authored-by: Copilot <copilot@github.com>
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>
TCPRoute graduated to GA with Gateway API v1.4, so the chart no longer needs to render the experimental
v1alpha2 version. Staying on an alpha API means depending on the Experimental CRD channel, which many
clusters do not install and which upstream may remove in a future release. Moving to the stable version
lets the chart work with the Standard CRD channel and aligns TCPRoute with HTTPRoute and BackendTLSPolicy,
which the chart already renders as v1.
The resource schema is unchanged between v1alpha2 and v1, so no field or value in
gatewayAPI.core.tcpRoute needs to be adjusted by users.
BREAKING CHANGE: TCPRoute is now rendered as gateway.networking.k8s.io/v1. Clusters must have Gateway API
CRDs v1.4 or newer installed when gatewayAPI.core.tcpRoute.enabled is true
### Description of the change
Remove the AWS S3 upload steps from the release workflow. Charts are now published only to Cloudflare R2 (plus the OCI registry on Docker Hub).
Removed steps:
- `aws credential configure` (`aws-actions/configure-aws-credentials`)
- `Copy files to S3 and clear cache`
The `awscli` install step is kept, since the Cloudflare R2 sync still uses `aws s3 sync` with a custom endpoint.
### Benefits
- One less publishing target to keep in sync, removing duplicated chart uploads.
- The `AWS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_REGION` and `AWS_S3_BUCKET` secrets are no longer needed.
### Possible drawbacks
Anything still pointing at the S3 bucket directly will no longer receive new chart releases; the Cloudflare R2 bucket behind `https://dl.gitea.com/charts` must be the only source of truth.
---------
Co-authored-by: bircni <bircni@icloud.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1103
Reviewed-by: bircni <bircni@icloud.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
The `check-actions-not-present` template and its unit test are no longer
needed since this is a new major version. Users have had sufficient time
to migrate to the dedicated helm-actions chart.
Migrate from bitnamicharts/valkey (and bitnamicharts/valkey-cluster) to the official Valkey Helm chart (https://valkey.io/valkey-helm, v0.10.0).
Changes:
- Remove valkey-cluster dependency and all related values, templates, and unit tests
- Update valkey dependency to use https://valkey.io/valkey-helm
- Adapt _helpers.tpl (valkey.dns, valkey.port, valkey.servicename) to the new chart's service naming and value structure
- Update values.yaml to match the new chart's configuration schema (auth.aclUsers instead of global.valkey.password, service.port instead of primary.service.ports.valkey, dataStorage instead of
primary.persistence)
- Update all affected unit tests
- Update README documentation
BREAKING CHANGE: valkey-cluster support has been removed. Users previously relying on valkey-cluster must migrate to standalone valkey or an external Redis-compatible service. The valkey values structure
has changed: `valkey.global.valkey.password` is now `valkey.auth.aclUsers.default.password`, and `valkey.primary.service.ports.valkey` is now `valkey.service.port`.
---------
Co-authored-by: rishub <183523+rishub@noreply.gitea.com>
Co-authored-by: rishub <itsrishub@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1097
Co-authored-by: Markus Pesch <markus.pesch@cryptic.systems>
The `helm plugin install` command fails when GnuPG is not available in
the container. Adding `--verify=false` skips signature verification to
allow the plugin to install in the Alpine-based CI environment.
Verify that PostgreSQL and PostgreSQL-HA service hostnames correctly
use a custom `clusterDomain` value instead of the default
`cluster.local` when connecting to the database.
volker.raschekandCopilot