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
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.
The following patch inherits the default values of the dependencies like
postgresql-ha, postgresql, valkey-cluster and valkey to disable persistent
storage.
For users, this is more obvious than having to look up the configuration options
in the dependencies or subcharts themselves.
The following PR add the annotation 'artifacthub.io/changes'. For each semantic
commit will be the annotation extended. Further information can be found in the
documentation of
[Artifacthub.io](https://artifacthub.io/docs/topics/annotations/helm/#supported-annotations).
The CI has been adapted. The binary jq as well as yq in >= v4.0 is required.
Otherwise will not be concatenated the YAML file correctly via the yq expression,
because the `loadstr()` expression is not available in lower versions.
Additionally the relation between the semantic commit and the Artifacthub.io
change log type should be clarified. The current relationshiop can be adapted if
needed.
Furthermore, yq will be installed as part of the CI steps. It would be great if
yq is also available as deb package in >=v4.0. This would reduce the boiler
plate to install yq and maintain the version via renovate.
Regarding the renovate expression. In my environment works this expression, but
I don't know if it also works in this gitea/renovate instance.
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/881
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Markus Pesch <markus.pesch@cryptic.systems>
Co-committed-by: Markus Pesch <markus.pesch@cryptic.systems>
The example of my latest PR based on a cpu resource limit of `100m`. But as the article describes, a cpu limit of lower than `1000m` or `1` can also lead to cpu throttling.
I've updates the README, to be correct and inform the user to take care of a correct cpu resource limit.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/795
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Markus Pesch <markus.pesch@cryptic.systems>
Co-committed-by: Markus Pesch <markus.pesch@cryptic.systems>
volker.raschekandCopilot