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.
This PR contains the following updates:
| Update | Change |
|---|---|
| lockFileMaintenance | All locks refreshed |
🔧 This Pull Request updates lock files to use the latest dependency versions.
---
### Configuration
📅 **Schedule**: (UTC)
- Branch creation
- At any time (no schedule defined)
- Automerge
- Between 12:00 AM and 03:59 AM (`* 0-3 * * *`)
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://github.com/renovatebot/renovate/discussions) if that's undesired.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xOTEuMiIsInVwZGF0ZWRJblZlciI6IjQzLjE5MS4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJraW5kL2RlcGVuZGVuY3kiXX0=-->Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1089
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Add full Gateway API support for exposing Gitea via HTTPRoute, TCPRoute, BackendTLSPolicy, and ClientSettingsPolicy resources.
New templates:
- `httpRoute.yaml` — renders an HTTPRoute with configurable
parentRefs, hostnames, and rules (defaults to PathPrefix `/`)
- `tcpRoute.yaml` — renders a TCPRoute for SSH traffic
- `backendTLSPolicy.yaml` — renders a BackendTLSPolicy for
encrypted backend connections with required validation config
- `clientSettingsPolicy.yaml` — renders an NGINX Gateway Fabric
ClientSettingsPolicy to raise the request body size limit
Infrastructure:
- `gatewayAPI.enabled` global toggle gates all resources
- Resources grouped under `gatewayAPI.core.*` and `gatewayAPI.nginx.*`
- Helper templates extracted into dedicated `_*.tpl` files
- Service name helpers (`gitea.service.http.name`, `gitea.service.ssh.name`)
extracted into `_services.tpl`; service templates renamed to camelCase
- `ROOT_URL`, `DOMAIN`, and `SSH_DOMAIN` auto-resolve from
`httpRoute.hostnames[0]`; `httpRoute.tls` switches to `https`
Documentation:
- New `docs/gateway-api.md` with topology examples, BackendTLSPolicy
setup, sectionName guidance, SSH considerations, and NGINX body
size limit configuration
- `.github/copilot-instructions.md` with project conventions
- README parameter table auto-generated via `make readme`
Tests:
- Helm unit tests for all four new resource templates
- Config tests for hostname/TLS resolution from Gateway API values
Co-authored-by: Todd Marimon <toddmarimon@gmail.com>
This PR contains the following updates:
| Update | Change |
|---|---|
| lockFileMaintenance | All locks refreshed |
🔧 This Pull Request updates lock files to use the latest dependency versions.
---
### Configuration
📅 **Schedule**: (UTC)
- Branch creation
- At any time (no schedule defined)
- Automerge
- Between 12:00 AM and 03:59 AM (`* 0-3 * * *`)
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://github.com/renovatebot/renovate/discussions) if that's undesired.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xOTEuMiIsInVwZGF0ZWRJblZlciI6IjQzLjE5MS4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJraW5kL2RlcGVuZGVuY3kiXX0=-->
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1087
Reviewed-by: silverwind <2021+silverwind@noreply.gitea.com>
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
### Description of the change
Add options to values.yaml to make chart easier to install in restricted openshift environments
### Benefits
more people can run this
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] 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`
- [x] Helm templating unittests are added (required when changing anything in `templates` folder)
- [ ] Bash unittests are added (required when changing anything in `scripts` folder)
- [x] All added template resources MUST render a namespace in metadata
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1063
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.com>
Co-committed-by: techknowlogick <techknowlogick@gitea.com>
### Description of the change
This change fixes an intermittent failure in the init password-reset flow caused by the CLI feature probe used to detect `--must-change-password` support.
The current probe uses:
`gitea admin user change-password --help | grep -qF -- '--must-change-password'`
Because `grep -q` exits immediately after the first match, it can close the pipe while gitea is still writing help output. In that case, gitea may return broken pipe.
This is timing-dependent, so it only reproduces sometimes with the same binary.
This PR replaces that check with a form that consumes the full output before exiting, avoiding premature pipe closure.
### Benefits
- Prevents intermittent broken pipe failures during init
- Makes password-reset capability detection deterministic
### Applicable issues
- Fixes#1051
### Additional information
No test update was required for this change.
The fix only adjusts the shell pipeline used in the rendered init script to avoid an intermittent broken pipe during the `--must-change-password` capability check. There are currently no existing Helm or bash unit tests covering this specific command path in the chart, and this change does not alter chart values, rendered resource structure, or template interfaces.
### Checklist
- [x] Bash unittests are added (required when changing anything in `scripts` folder)
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1052
Co-authored-by: alexandru-marianlita <alexandru-marian.lita@spirent.com>
Co-committed-by: alexandru-marianlita <alexandru-marian.lita@spirent.com>
For various internal reasons we're not currently running gitea via the Helm chart right now, so I'm not in the same position I was before to review and test patches.
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1047
Co-authored-by: Ross Golder <ross@golder.org>
Co-committed-by: Ross Golder <ross@golder.org>
### Description of the change
Gitea supports providing DB and Redis/ValKey secrets via env variables, current chart requires DB and Redis/ ValKey credentials reading from k8s secret as per below values.yaml snippet. This approach requires secret to be created beforehand.
```
- name: GITEA__database__USER
valueFrom:
secretKeyRef:
name: gitea-ha
key: db_user
- name: GITEA__database__PASSWD
valueFrom:
secretKeyRef:
name: gitea-ha
key: db_password
```
Other approach is to provide the credentials in values.yaml which isnt secure.
A bash variable file can be created by using vault injector like this, which then can be sourced while running `config_environment.sh` in `init-app-ini`
```
GITEA__database__NAME=gitea
GITEA__database__USER=gitea_user
```
Support to read env variables from file
Reference: https://developer.hashicorp.com/vault/docs/deploy/kubernetes/injector/examples#environment-variable-example
### Benefits
Support to read env variables from file created by vault injector for DB and redis/ valkey credentials
Support to set gitea admin user and credentials via env variables from file created by vault injector
### Possible drawbacks
N/A
### ⚠ BREAKING
No breaking changes
### Checklist
- [X] 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)
---------
Co-authored-by: techknowlogick <techknowlogick@gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/993
Co-authored-by: deepakdeore2004 <deepakdeore2004@noreply.gitea.com>
Co-committed-by: deepakdeore2004 <deepakdeore2004@noreply.gitea.com>
### Description of the change
I've added the root label to the valkey domain that is searched by nc in the `configure_gitea.sh` script.
Here is an example of what the `test_valkey_connection` function will look like to the `configure-gitea` container:
```
function test_valkey_connection() {
local RETRY=0
local MAX=30
echo 'Wait for valkey to become avialable...'
until [ "${RETRY}" -ge "${MAX}" ]; do
nc -vz -w2 gitea-dev-valkey-cluster-headless.gitea-dev.svc.cluster.local. 6379 && break
RETRY=$[${RETRY}+1]
echo "...not ready yet (${RETRY}/${MAX})"
done
if [ "${RETRY}" -ge "${MAX}" ]; then
echo "Valkey not reachable after '${MAX}' attempts!"
exit 1
fi
}
```
### Benefits
If a search domain is set in resolve.conf, nc will append that root domain to the lookup, causing the lookup to fail. This will allow users to have a search domain set without causing the configure script to fail.
### Possible drawbacks
I don't believe there are any drawbacks, but let me know if I'm wrong.
### Applicable issues
gitea/helm-gitea#972
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/982
Reviewed-by: Markus Pesch <volker.raschek@noreply.gitea.com>
Co-authored-by: David Chatterton <david@davidchatterton.com>
Co-committed-by: David Chatterton <david@davidchatterton.com>
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.
This PR removes the inclusion of `deployment.labels` in the Deployment's `selector.matchLabels` field.
## Changes
- Removed the conditional block that adds `deployment.labels` to `selector.matchLabels`
- This ensures the selector remains immutable and only contains pod-identifying labels
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1011
Reviewed-by: Markus Pesch <volker.raschek@noreply.gitea.com>
Co-authored-by: Tarun Gaba <tarun.gaba7@gmail.com>
Co-committed-by: Tarun Gaba <tarun.gaba7@gmail.com>
This PR contains the following updates:
| Update | Change |
|---|---|
| lockFileMaintenance | All locks refreshed |
🔧 This Pull Request updates lock files to use the latest dependency versions.
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC).
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://github.com/renovatebot/renovate/discussions) if that's undesired.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS4xOC4xIiwidXBkYXRlZEluVmVyIjoiNDEuMTguMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsia2luZC9kZXBlbmRlbmN5Il19-->
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/994
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
### Description of the change
When the template is rendered, preceding whitespace is removed, creating
a yaml object like `---apiVersion: ...` which `helm template` can handle
but `helm lint` fails on as discussed in
https://github.com/helm/helm/issues/10149. By not removing this
whitespace, templates render correctly.
### Benefits
`helm lint` will pass
### Possible drawbacks
`helm diff` and similar tools might display whitespace changes, but no semantic changes.
### Checklist
Added no unit tests because there are non for `extraDeploy`.
- [ ] Helm templating unittests are added (required when changing anything in `templates` folder)
Co-authored-by: javex <code@inexplicity.de>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/915
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Javex <javex@noreply.gitea.com>
Co-committed-by: Javex <javex@noreply.gitea.com>
This PR contains the following updates:
| Update | Change |
|---|---|
| lockFileMaintenance | All locks refreshed |
🔧 This Pull Request updates lock files to use the latest dependency versions.
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - Between 12:00 AM and 03:59 AM ( * 0-3 * * * ) (UTC).
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://github.com/renovatebot/renovate/discussions) if that's undesired.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS4xOC4xIiwidXBkYXRlZEluVmVyIjoiNDEuMTguMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsia2luZC9kZXBlbmRlbmN5Il19-->
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/985
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
The following patch intoduce the dictionaries pre and postExtraInitContainers.
The dictionaries can be used to specify further initContainers before and after
the gitea initializing process. For example:
```yaml
postExtraInitContainers:
- name: foo
image: docker.io/library/busybox:latest
preExtraInitContainers:
- name: bar
image: docker.io/library/busybox:latest
```
#916
After many years of maintaining this chart alongside @justusbunsi, I am also stepping down as a maintainer.
In the following, I want to inform users about the reasons.
I am on an independent journey since ~ 1 year, which brought many new challenges and responsibilities.
Since then I have created many devops-related assets (charts, Ansible role, images) which I am now curating as part of my professional work.
Besides, I have also continued with all my FOSS-related efforts. This has summed up to ~ 20-30 projects for which I am either in a primary or secondary maintainer role.
While I have a lot of fun in this, I need to ensure to not go beyond my limits and focus on the ones which I also use in my daily dev & professional life.
Gitea isn't among these anymore since some time, which brings me to the second part of why I am stepping down:
After thinking about it for a long time and being torn between worlds, I've decided to go with Forgejo instead of Gitea for most instances I am running/maintaining.
Since then, I have used the Gitea helm chart to deploy these. This has worked out great and without issues and will likely continue to do so for the foreseeable future.
However, it lately started to feel "wrong", i.e. to continue using the Gitea chart for Forgejo deployments, especially after both projects have substantially diverged some time ago already and a Forgejo Helm Chart exists since some time. Also, I had the feeling of not being able to "commit" to one of the projects fully, being involved in both.
After launching [CodeFloe](https://codefloe.com) a few weeks ago, a public Forgejo instance, I came to the conclusion to step down as a maintainer and focus on the software that I use daily.
And as I like be fully transparent: I don't wanna hold back on the fact that I was also missing the community spirit from "the old days" quite a bit lately, both in the Discord server and the discussions in the chart. The ratio of low-quality requests in the Chart increased a lot over the last ~ 1.5 years, while at the same time the average response times of Gitea core member increased to weeks.
I hope the Gitea community can turn this around again and create a welcoming place to which its fun to contribute to in one's spare time. I enjoyed it for the most part and want to thank everyone who supported me during this time, for the general trust in Chart-related decisions, and the opportunity to personally improve on Helm chart management in general.
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/918
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
This is a direct follow-up to https://gitea.com/gitea/helm-gitea/issues/916.
Over the past months I took an unofficial break. During this time I realized that I don't have the necessary energy and spare time to maintain the Helm Chart long-term - in a way I would like to. Before that break I had ups where I was hyper-focused on the chart, and downs where everything was too much after work. I never found a sweat spot between both. This is not good for me. It is therefore with a heavy heart that I am stepping down as a maintainer.
Signed-off-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/917
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.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. -->
Fix broken docs links. 😉
### 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. -->
- none
### 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. -->
regression of #775
### ⚠ 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/904
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Co-committed-by: Michael Kriese <michael.kriese@visualon.de>
### Add new 'srCheckPassword' postgresql-ha value to support new postgresql-ha stream replication check requirements
Per Bitnami's [documentation](https://github.com/bitnami/charts/tree/main/bitnami/postgresql-ha#to-1600), a new 'sr_check_user' now exists for the purpose of pgpool preforming stream replication checking.
### Benefits
This change allows customizing that role's password by overriding Bitnami's chart value.
### Possible drawbacks
None that I'm aware of.
### Applicable issues
- Fixes#888
### Additional information
Per #888, the Bitnami PR where customizable stream reapplication check credentials were introduced is https://github.com/bitnami/charts/pull/33552
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] 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)
- [x] Helm templating unittests are added (required when changing anything in `templates` folder)
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/894
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Jade Deane <jade.deane@gmail.com>
Co-committed-by: Jade Deane <jade.deane@gmail.com>
For rootful Gitea images, the built-in OpenSSH server is reused, and Gitea itself does not listen on any SSH port. Therefore, the `SSH_LISTEN_PORT` setting has no effect. Explicitly setting `START_SSH_SERVER` helps avoid confusion and makes the behavior clearer.
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/876
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-committed-by: Lunny Xiao <xiaolunwen@gmail.com>
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>
Following the creation of the changelog via `git-sv`, the release process can also be simplified.
The new approach only requires to call `git sv tag` from a Maintainer with write access to the repo.
This will create and push the tag.
The release notes and subsequent Gitea release will then be created by the new workflow job.
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/865
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
### Description of the change
Redesigned ingress configuration to align better with implicit best practices.
### Benefits
- Smarter defaults
- More tests
- Remove [deprecated API Versions](extensions/v1beta1) (e.g. `extensions/v1beta1`) and always use `networking.k8s.io/v1`
### Possible drawbacks
Hopefully 🙃 none
### Applicable issues
fix#674
### Additional information
- Define `ingress.annotations` via helpers
- Move tests from `tests/deployment` to `tests/ingress`
- Use own tests file for ingress tpl tests
- Ensure defaults of `path` and `pathType` are always rendered
- Set top-level default value for `ingress. pathType`
- Change default of `ingress.hosts[0].paths` to `[]` to ensure proper rendering via template
### ⚠ BREAKING
I think all of these changes should be backward comp with existing ingress definitions, but surely worth highlighting in the changelog of the release.
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] 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)
- [x] Breaking changes are documented in the `README.md`
- [x] Templating unittests are added
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/679
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.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
Migrates from Redis to Valkey.
### Benefits
The Redis License is changing from BSD-3-Clause to RSALv2 and SSPLv1 which are not open source under the OSI definition. We should consider open-source alternatives as a default replacement for Redis.
### Possible drawbacks
Large scale change, potentially breaking.
### Applicable issues
https://github.com/go-gitea/gitea/issues/32056
### ⚠ BREAKING
Major version change, redis provider changed to valkey.
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [X] 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)
- [X] Breaking changes are documented in the `README.md`
- [X] Helm templating unittests are added (required when changing anything in `templates` folder)
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/775
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Sean Teo <sawntoe@gmail.com>
Co-committed-by: Sean Teo <sawntoe@gmail.com>
The Renovate config in this repository needs migrating. Typically this is because one or more configuration options you are using have been renamed.
You don't need to merge this PR right away, because Renovate will continue to migrate these fields internally each time it runs. But later some of these fields may be fully deprecated and the migrations removed. So it's a good idea to merge this migration PR soon.
#### [PLEASE NOTE](https://docs.renovatebot.com/configuration-options#configmigration): JSON5 config file migrated! All comments & trailing commas were removed.
🔕 **Ignore**: Close this PR and you won't be reminded about config migration again, but one day your current config may no longer be valid.
❓ Got questions? Does something look wrong to you? Please don't hesitate to [request help here](https://github.com/renovatebot/renovate/discussions).
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/861
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This is @ChristopherHX's PR
### Description of the change
Do not silently ignore actions.enabled set by user.
### Benefits
Everybody who has enabled actions act_runner do not silently end up without runners, but directly see an actionable error message.
### Possible drawbacks
You need to remove the actions section from your own values.yml to upgrade/install this chart.
The Migration Guide has not been written yet, I consider this issue as a community wiki where other maintainers are free to edit my initial post.
### Applicable issues
N/A
### Additional information
I couldn't add helm-gitea as a dependency, because of
- conflict with https://gitea.com/gitea/helm-gitea/src/commit/a7035ca4e56ed5cdff3e6130a83d9c1742b29ccf/templates/_helpers.tpl#L223-L230
with one difference helm-actions did not have the referenced values and failed to render
- after resolving the above by either renaming in the helm-actions chart or removal of this leftover code in helm-gitea
- helm does not allow me to derive dynamic default values for the `actions` section for the subchart
- using yaml anchors only provided default values into helm-actions, without respecting user changes
- I only found a feature request
- It is not feasible for me in short term to add support of this section back using helm-actions
### Checklist
- [X] Helm templating unittests are added (required when changing anything in `templates` folder)
Co-authored-by: Christopher Homberger <christopher.homberger@web.de>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/849
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: techknowlogick <techknowlogick@noreply.gitea.com>
Co-committed-by: techknowlogick <techknowlogick@noreply.gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| unittests/bash/test_helper/bats-assert | digest | `e2d855b` -> `0ec504e` |
---
### Configuration
📅 **Schedule**: Branch creation - "* * * * 0,6" (UTC), Automerge - "* 0-3 * * *" (UTC).
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xOTAuMCIsInVwZGF0ZWRJblZlciI6IjM5LjE5MC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJraW5kL2RlcGVuZGVuY3kiXX0=-->
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/826
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
https://github.com/thegeeklab/git-sv
- Creates a changelog from conventional commits
- Updates the changelog in an static issue (creates the issue if missing)
- Only runs after a new commit was merged into `main`
- Automatically determines the next version based on conv commits logic
- Follows up on #788
---
The logic can also be used to create the release notes on `tag` events and the subsequent Gitea release. Didn't wanted to add all at once, though.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/794
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
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>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| unittests/bash/bats | digest | `b640ec3` -> `7ca23b1` |
---
### Configuration
📅 **Schedule**: Branch creation - "* * * * 0,6" (UTC), Automerge - "* 0-3 * * *" (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS43NS4xIiwidXBkYXRlZEluVmVyIjoiMzkuMTE4LjIiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbImtpbmQvZGVwZW5kZW5jeSJdfQ==-->
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/754
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
### Description of the change
In the act_runner StatefulSet, this allows to mount volumes.
### Benefits
It allows to mount some volumes in any of the two containers, e.g. certificates for a private registry.
### Possible drawbacks
I can't think of any.
### Applicable issues
- Fixes#744
### Checklist
- [X] 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)
- [X] Helm templating unittests are added (required when changing anything in `templates` folder)
Co-authored-by: Xav <grandmou@protonmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/756
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: grandmou <grandmou@noreply.gitea.com>
Co-committed-by: grandmou <grandmou@noreply.gitea.com>
### Description of the change
This adds an environment for unit testing our bash scripts, using [BATS](https://github.com/bats-core/bats-core).
It implements first tests for `config_environment.sh`.
### Benefits
Writing unit tests for bash scripts documents the expected behavior and allows it being a quality gate in our CI.
### Possible drawbacks
Not everyone is familiar with this approach and unit testing framework. Me neither, it took me some hours to get into it.
### Applicable issues
- Related to #691 where an issue in `config_environment.sh` was detected. It doesn't fixes it yet. This will be a dedicated Pull Request.
### Additional information
I've verified that the changes for Renovate are indeed working.
You may wonder why there is only one `run $PROJECT_ROOT/scripts/init-containers/config/config_environment.sh` and many `run execute_test_script` calls.
Usually, testing a script itself would be executing `run $PROJECT_ROOT/scripts/init-containers/config/config_environment.sh`. You then can assert the exit code and other things. Since the `config_environment.sh` exports environment variables and we are not able to access them from outside a `run` execution, the function `execute_test_script` wraps our script execution between environment comparison. Doing so allows us capture environment variables that were added/removed during script execution.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/724
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
### Description of the change
This is a preparation for #724 (bash script testing) which would be too complex to review if done there. I haven't changed the script contents.
### Benefits
Better IDE support, possibility for shell checks, tests.
### Possible drawbacks
-
### Additional information
I only extracted files that are native bash scripts. There are others, being a mix of Helm templating and shell scripts. Those scripts must be cleared first before extracting them as well.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/751
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
### Description of the change
This addresses 2 bugs regarding configured runner labels:
- `Cannot find: node in PATH` due to a default label that matches the runner host, not the docker-in-docker environment
- After changing the runner config, users have to manually replace the StatefulSet Pod of the runner
### Benefits
- Out-of-the-box functioning node environment
- Auto-updated runner config on changes in values
### Applicable issues
- fixes https://gitea.com/gitea/helm-chart/issues/728
- fixes https://gitea.com/gitea/helm-chart/issues/725
### Additional information
With removing the default labels from `values.yaml`, the act runner defaults will be used for new runners which fixes the "missing node" issue.
I had issues replacing the labels once the Chart defaults were used, so users might have to replace their runner manually if this is an issue.
### Checklist
- [x] Templating unittests are added
Signed-off-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/739
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
### Benefits
Can protect metrics endpoint with `Bearer` token authentication provided by gitea.
see PR #637 for previous discussion.
### Possible drawbacks
No possible drawbacks
### Applicable issues
- fixes#635
### Additional information
```
gitea:
metrics:
enabled: true
token: "somepassword"
serviceMonitor:
enabled: true
```
Using above configuration is sufficient to secure /metrics endpoint with bearer token and corresponding ServiceMonitor.
### Checklist
- [x] 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`~~ Not applicable
- [x] Templating unittests are added
Signed-off-by: Hitesh Nayak <hiteshnayak305@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/719
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: Hitesh Nayak <hiteshnayak305@gmail.com>
Co-committed-by: Hitesh Nayak <hiteshnayak305@gmail.com>
When the _init-directories_ container runs, the shell script _init_directory_structure.sh_ logs to _stderr_ because debugging is enabled with _set -x_. The output from the script, should be logged to _stdout_ instead. The issue is discussed here: https://gitea.com/gitea/helm-chart/issues/701
### Description of the change
This PR uses the _verbose_ flag with all commands in the script to log what the script is doing.
### Benefits
Log entries with incorrect severity _ERROR_ will no longer be logged in _Kubernetes_.
### Possible drawbacks
Log output will change. If someone had a check for certain log entries from the _init container_, that check would break.
### Checklist
Updated unit tests.
Co-authored-by: tobias.petersen <tobias.petersen@unity3d.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/708
Reviewed-by: techknowlogick <techknowlogick@noreply.gitea.com>
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: tobiasbp <tobiasbp@noreply.gitea.com>
Co-committed-by: tobiasbp <tobiasbp@noreply.gitea.com>
### Description of the change
Introduce `service.{http,ssh}.loadBalancerClass`
### Benefits
Feature was not supported before. This is required if your cluster has multiple loadBalancer options and you want to select one
### Possible drawbacks
More yaml.
### Checklist
- [x] 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)
- [x] Templating unittests are added
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/640
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Karitham <kar@karitham.dev>
Co-committed-by: Karitham <kar@karitham.dev>
Right now, the generated `.prov` file is not uploaded along with the actual `.tgz` file. This makes it impossible to verify our Helm Charts.
In addition, we only sign the old-fashioned `.tgz` file, not the OCI-based releases on DockerHub.
The incentive to do this very commit is an expired GPG key that prevents our release.
Signed-off-by: justusbunsi <sk.bunsenbrenner@gmail.com>
### Description of the change
This enables sane modes for forcing reset, as well as providing more options to users of the chart by giving them the flexibility to set the mode for password creation/modification as part of init whether the user exists or not.
### Benefits
The new default should revert to the behavior before #673 became an issue, while also providing more flexibility for users who want to be able to manage their initial admin user password out-of-band after creating it the first time.
### Possible drawbacks
None that I can think of.
### Applicable issues
- fixes#673
### Additional information
See the discussion in #675 as well
### Checklist
- [X] 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)
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/677
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: James Harmison <jharmison@gmail.com>
Co-committed-by: James Harmison <jharmison@gmail.com>
### Description of the change
Adding support for DRY principle (via use of the TPL function) to the PVC storage class and the ingress class
### Benefits
It allows to reference a variable into another one to avoid duplicating them (or using YAML anchors).
It is useful and valuable when including Gitea into an umbrella chart with multiple components and to have a single variable while the components variable only refer to that single one.
Example 1
```
global:
persistence:
storageClass: "storage-class"
persistence:
storageClass: "{{ .Values.global.persistence.storageClass }}"
```
This results in having `spec.storageClassName` equal to `storage-class` in the PVC object
Example 2
```
global:
ingress:
className: "ingress-class"
ingress:
className: "{{ .Values.global.ingress.className}}"
```
This results in having `spec.ingressClassName` equal to `ingress-class` in the Ingress object
### Possible drawbacks
N/A
### Checklist
- [X] Templating unittests are added
Co-authored-by: 212597596 <cedric.henry@ge.com>
Co-authored-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/664
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Ceddaerrix <ceddaerrix@noreply.gitea.com>
Co-committed-by: Ceddaerrix <ceddaerrix@noreply.gitea.com>
@justusbunsi
I've been running 1.22 with this chart on some clusters for some days now without issues.
I think no further adjustments are needed on the chart side.
Maybe we can get some of the other open PRs in?
Also: Let me know if you want to do the release this time - I did a lot lately, happy to let you have a go for this one :)
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/662
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [redis-cluster](https://github.com/bitnami/charts) ([source](https://github.com/bitnami/charts/tree/HEAD/bitnami/redis-cluster)) | major | `9.8.1` -> `10.0.1` |
---
### Configuration
📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - "before 4am" (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yNDYuMSIsInVwZGF0ZWRJblZlciI6IjM3LjI3OS4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/629
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [postgresql](https://github.com/bitnami/charts) ([source](https://github.com/bitnami/charts/tree/HEAD/bitnami/postgresql)) | major | `14.3.3` -> `15.2.5` |
---
### Configuration
📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - "before 4am" (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yNjYuMCIsInVwZGF0ZWRJblZlciI6IjM3LjI4MC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/634
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [postgresql-ha](https://github.com/bitnami/charts) ([source](https://github.com/bitnami/charts/tree/HEAD/bitnami/postgresql-ha)) | patch | `14.0.0` -> `14.0.2` |
---
### Configuration
📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - "before 4am" (UTC).
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yNzkuMyIsInVwZGF0ZWRJblZlciI6IjM3LjI3OS4zIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJraW5kL2RlcGVuZGVuY3kiXX0=-->
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/638
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [postgresql-ha](https://github.com/bitnami/charts) ([source](https://github.com/bitnami/charts/tree/HEAD/bitnami/postgresql-ha)) | major | `13.6.1` -> `14.0.0` |
---
### Configuration
📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - "before 4am" (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yNDYuMSIsInVwZGF0ZWRJblZlciI6IjM3LjI0Ni4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/628
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
The current README content is a result of running markdownlint with simple fixes enabled.
It shouldn't fix _any_ issues, even after generating the parameter section.
Unfortunately, this is not the case right now.
This resolves the long-running dispute of both tools. 😉
---
Since I already modified the `values.yaml`, I decided to include a change regarding code signing.
Otherwise, it may confuse users after merging #596.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/627
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [postgresql-ha](https://github.com/bitnami/charts) ([source](https://github.com/bitnami/charts/tree/HEAD/bitnami/postgresql-ha)) | major | `12.8.2` -> `13.4.5` |
---
### Configuration
📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - "before 4am" (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yMjIuMyIsInVwZGF0ZWRJblZlciI6IjM3LjIyNC4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/624
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [postgresql](https://github.com/bitnami/charts) ([source](https://github.com/bitnami/charts/tree/HEAD/bitnami/postgresql)) | major | `13.4.6` -> `14.2.3` |
---
### Configuration
📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - "before 4am" (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yMjIuMyIsInVwZGF0ZWRJblZlciI6IjM3LjIyMi4zIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/622
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [redis-cluster](https://github.com/bitnami/charts) ([source](https://github.com/bitnami/charts/tree/HEAD/bitnami/redis-cluster)) | minor | `9.5.20` -> `9.6.2` |
---
### Configuration
📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - "before 4am" (UTC).
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yMTAuMCIsInVwZGF0ZWRJblZlciI6IjM3LjIxMC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/617
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [crazy-max/ghaction-import-gpg](https://github.com/crazy-max/ghaction-import-gpg) | action | major | `v5` -> `v6` |
---
### Release Notes
<details>
<summary>crazy-max/ghaction-import-gpg (crazy-max/ghaction-import-gpg)</summary>
### [`v6`](https://github.com/crazy-max/ghaction-import-gpg/compare/v5...v6)
[Compare Source](https://github.com/crazy-max/ghaction-import-gpg/compare/v5...v6)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - "before 4am" (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yMTIuMCIsInVwZGF0ZWRJblZlciI6IjM3LjIxMi4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/620
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
Hi,
In reference to #580
I noticed that one cannot apply labels to the created PVC with persistance.labels.
The label statement is missing in the template.
best regards,
Oliver.
**helm-chart/templates/gitea/pvc.yaml:**
```
{{- if and .Values.persistence.enabled .Values.persistence.create }}
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: {{ .Values.persistence.claimName }}
namespace: {{ $.Release.Namespace }}
annotations:
{{ .Values.persistence.annotations | toYaml | indent 4}}
spec:
...
```
**values.yaml:**
```
persistence:
## @param primary.persistence.enabled Enable PostgreSQL Primary data persistence using PVC
##
enabled: true
## @param primary.persistence.existingClaim Name of an existing PVC to use
##
existingClaim: ""
## @param primary.persistence.mountPath The path the volume will be mounted at
## Note: useful when using custom PostgreSQL images
##
mountPath: /bitnami/postgresql
## @param primary.persistence.subPath The subdirectory of the volume to mount to
## Useful in dev environments and one PV for multiple services
##
subPath: ""
## @param primary.persistence.storageClass PVC Storage Class for PostgreSQL Primary data volume
## If defined, storageClassName: <storageClass>
## If set to "-", storageClassName: "", which disables dynamic provisioning
## If undefined (the default) or set to null, no storageClassName spec is
## set, choosing the default provisioner. (gp2 on AWS, standard on
## GKE, AWS & OpenStack)
##
storageClass: ""
## @param primary.persistence.accessModes PVC Access Mode for PostgreSQL volume
##
accessModes:
- ReadWriteOnce
## @param primary.persistence.size PVC Storage Request for PostgreSQL volume
##
size: 8Gi
## @param primary.persistence.annotations Annotations for the PVC
##
annotations: {}
## @param primary.persistence.labels Labels for the PVC
##
labels: {}
```
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] 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)
Co-authored-by: pat-s <pat-s@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/581
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Oliver Fueckert <oliver@cubinet.de>
Co-committed-by: Oliver Fueckert <oliver@cubinet.de>
### Description of the change
The change allows users of this chart to specify custom labels for the HTTP & SSH Services that get deployed. They are optional and if given are added to the standard list of labels.
### Benefits
Certain use cases require labelling services to be able to select them in other places. Specifiying them directly in the helm chart avoids having to label by hand everytime.
Concrete Use Case Example: Cilium Layer 2 Announcements require selecting services to announce via labels (see [docs](https://docs.cilium.io/en/stable/network/l2-announcements/#service-selector)). I would like to add a label to the SSH service, but not the HTTP Service (which is handled via an ingress).
### Possible drawbacks
I don't see any, using this feature is optional :)
### Checklist
- [X] 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)
- [X] Breaking changes are documented in the `README.md`
- [X] Templating unittests are added
Co-authored-by: Remo Geissbühler <git@remogeissbuehler.ch>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/597
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: remogeissbuehler <remogeissbuehler@noreply.gitea.com>
Co-committed-by: remogeissbuehler <remogeissbuehler@noreply.gitea.com>
### Description of the change
With https://github.com/go-gitea/gitea/pull/28390, Gitea 1.21.2 introduced warning log output within the result of `gitea admin <subcommand>` and therefore affects the current provisioning script.
That script previously assumed a clean result set and was therefore doomed to fail at _some_ point.
This introduces output sanitizing to trim such logs above the actual result table.
### Applicable issues
- fixes#589
### Additional information
The non-sanitized output were only an issue for admin account provisioning, and only when the username matched one of these words (in case of #589 it was `gitea`):
```text
.../setting/security.go:168:loadSecurityFrom() [W] Enabling Query API Auth tokens is not recommended. DISABLE_QUERY_AUTH_TOKEN will default to true in gitea 1.23 and will be removed in gitea 1.24.
```
LDAP and OAuth sources were not affected by this particular log line, but also processed non-sanitized result sets. Changing their code is a precaution.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/590
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
### Description of the change
Add config fallbacks for `session`, `cache` and `queue` including tests.
### Benefits
If users disable the default `redis-cluster` sub-chart dependency, this will configure the respective sections to use the Gitea defaults as listed in https://docs.gitea.com/next/administration/config-cheat-sheet.
### Possible drawbacks
Users will run on non-optimal settings for production without knowing their config.
### Applicable issues
- fixes#584#573#489#476#468#453
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] 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)
- [x] Breaking changes are documented in the `README.md`
- [x] Templating unittests are added
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/585
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [postgresql](https://github.com/bitnami/charts) ([source](https://github.com/bitnami/charts/tree/HEAD/bitnami/postgresql)) | major | `12.12.10` -> `13.2.24` |
---
### Configuration
📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - "before 4am" (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy44MS40IiwidXBkYXRlZEluVmVyIjoiMzcuODMuMiIsInRhcmdldEJyYW5jaCI6Im1haW4ifQ==-->
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/579
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [postgresql-ha](https://github.com/bitnami/charts) ([source](https://github.com/bitnami/charts/tree/HEAD/bitnami/postgresql-ha)) | major | `11.9.4` -> `12.3.1` |
---
### Configuration
📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - "before 4am" (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy44LjEiLCJ1cGRhdGVkSW5WZXIiOiIzNy43Ny4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/528
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
While working on #409, I noticed that some unittests contains either
invalid assertion methods (`isNotEmpty`) or invalid properties (`any`)
for a specific assertion method (`notContains`).
As our tests pass - and I have ensured that they can fail - this seems
related to the YAML schema validation in the IDE.
I've noticed that `isNotEmpty` was replaced by `isNotNullOrEmpty`[^1]
in version v0.3.2[^2]. At least from a schema validation point of view.
It is still working. Maybe deprecated? I don't know.
Regarding the `any` property, the documentation seems incorrect. I've
filed a PR for it[^3]. As soon as that PR is merged and released, we
could probably validate the test YAML files in our PR workflow.
Last, since we renovate the used helm-unittest version, we should also
renovate the used YAML schema file.
[^1]: https://github.com/helm-unittest/helm-unittest/pull/139
[^2]: https://github.com/helm-unittest/helm-unittest/releases/tag/v0.3.2
[^3]: https://github.com/helm-unittest/helm-unittest/pull/243
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/570
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
As seen in #507 and #569, there is no guarantee for us that minor
dependency updates are actually minor updates for the dependent
application itself. The Chart version might be minor - and therefore
automatically merged when build is green - but the used Docker image
inside the Chart could still be a major version change.
To effectively prevent such automerge when the application major version
changes, there is now a test file that has the currently used major
versions hard-coded. In case of an actual major bump, this file has to
be adjusted.
Looking at `redis-cluster`, there might be several major Chart versions
with the same major application version.
This PR is related to #409 but does not fully resolve it.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/571
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
### Description of the change
This PR is a continuation of the work done by @dgershman in [534](https://gitea.com/gitea/helm-chart/pulls/534), to allow users to override the image from the default rootless behavior of appending `-rootless` to the end of the image tag.
### Benefits
Allows more flexibility to use externally maintained images that are rootless but don't follow the `-rootless` tag convention.
### Applicable issues
- fixes#532
### Additional information
No breaking changes. This does not affect the `image.rootless` conditional checks or the current behavior if someone still wants to rely on the chart to append `-rootless`.
### Checklist
- [x] 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)
- [x] Breaking changes are documented in the `README.md`
- [x] Templating unittests are added
Co-authored-by: TristanHoladay <40547442+TristanHoladay@users.noreply.github.com>
Co-authored-by: pat-s <pat-s@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/550
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: TristanHoladay <tristanholaday@noreply.gitea.com>
Co-committed-by: TristanHoladay <tristanholaday@noreply.gitea.com>
### Description of the change
This adds a `.vscode` folder with recommended extensions and some useful settings like unittest schema validation.
The `.vscode` folder is already helm ignored during packaging.
### Possible drawbacks
We would have to be careful about PR changes in that directory.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/536
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
### Description of the change
We are affected by a regression of a Helm bug from May 2023. I've tested
the Helm versions 3.13.1, 3.13.0 and 3.12.3. Both 3.13.x are affected.
3.12.3 works. So let's downgrade and drop the docker login in PR builds.
I've also switched the `apt install helm` with an official `alpine/helm`
image I am using at work. Pinning the helm version and receiving updates
helps us identifying such issues in the future.
For the release workflow I was a bit more reluctant with changes, since
I cannot easily test them. That's why I just pinned the Helm version.
Renovate will provide one PR changing both files because it's the same
dependency (alpine/helm) from the same datasource (docker).
https://github.com/helm/helm/issues/12062
### Applicable issues
- implicitly fixes#527
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/535
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
### Description of the change
Introducing `tpl` function on variables related to hostname in `./templates/gitea/ingress.yaml`
### Benefits
The change is intending to support the following syntax in a values.yaml such as:
```
global:
giteaHostName: "gitea.my-org.com"
ingress:
enabled: true
hosts:
- host: "{{ .Values.global.giteaHostName }}"
paths:
- path: /
pathType: Prefix
tls:
- secretName: gitea-tls
hosts:
- "{{ .Values.global.giteaHostName }}"
```
### Possible drawbacks
N/A
### Applicable issues
N/A
### Additional information
N/A
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/498
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: Ceddaerrix <ceddaerrix@noreply.gitea.com>
Co-committed-by: Ceddaerrix <ceddaerrix@noreply.gitea.com>
As title. This modification should only apply the minor+patch updates for the helm deps of this chart on a weekly basis. Major updates should still come in with the daily renovate runs.
Automerge is included but won't work as the bot cannot self-approve it's PRs and does not have merge permissions yet.
The only way this might work if we allow the bot to push to a branch only and merge without opening a PR.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/510
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [redis-cluster](https://github.com/bitnami/charts) | major | `8.8.2` -> `9.0.4` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNi43OS4xIiwidXBkYXRlZEluVmVyIjoiMzYuODkuMCIsInRhcmdldEJyYW5jaCI6Im1haW4ifQ==-->
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/504
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [postgresql](https://github.com/bitnami/charts) | patch | `12.10.0` -> `12.10.1` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNi43OS4xIiwidXBkYXRlZEluVmVyIjoiMzYuNzkuMSIsInRhcmdldEJyYW5jaCI6Im1haW4ifQ==-->
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/505
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [redis-cluster](https://github.com/bitnami/charts) | minor | `8.6.9` -> `8.8.2` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNi43OS4xIiwidXBkYXRlZEluVmVyIjoiMzYuNzkuMSIsInRhcmdldEJyYW5jaCI6Im1haW4ifQ==-->
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/503
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [markdownlint-cli](https://github.com/igorshubovych/markdownlint-cli) | devDependencies | minor | [`^0.35.0` -> `^0.36.0`](https://renovatebot.com/diffs/npm/markdownlint-cli/0.35.0/0.36.0) |
---
### Release Notes
<details>
<summary>igorshubovych/markdownlint-cli (markdownlint-cli)</summary>
### [`v0.36.0`](https://github.com/igorshubovych/markdownlint-cli/releases/tag/v0.36.0): 0.36.0
[Compare Source](https://github.com/igorshubovych/markdownlint-cli/compare/v0.35.0...v0.36.0)
- Update `markdownlint` dependency to `0.30.0`
- Use `micromark` in MD022/MD026/MD032/MD037/MD045/MD051
- Incorporate `micromark-extension-math` for math syntax
- Allow custom rules to override information URL
- Update all dependencies via `Dependabot`
</details>
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNi43OS4xIiwidXBkYXRlZEluVmVyIjoiMzYuNzkuMSIsInRhcmdldEJyYW5jaCI6Im1haW4ifQ==-->
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/500
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [postgresql-ha](https://github.com/bitnami/charts) | patch | `11.9.0` -> `11.9.2` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNi43OS4xIiwidXBkYXRlZEluVmVyIjoiMzYuNzkuMSIsInRhcmdldEJyYW5jaCI6Im1haW4ifQ==-->
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/499
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| postgresql | minor | `12.6.6` -> `12.10.0` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNS4xMTguMCIsInVwZGF0ZWRJblZlciI6IjM1LjExOC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Co-authored-by: techknowlogick <techknowlogick@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/495
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| postgresql-ha | minor | `11.7.9` -> `11.9.0` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNS4xMTguMCIsInVwZGF0ZWRJblZlciI6IjM1LjExOC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Co-authored-by: techknowlogick <techknowlogick@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/496
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
Welcome to [Renovate](https://github.com/renovatebot/renovate)! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.
🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.
---
### Detected Package Files
* `values.yaml` (helm-values)
* `Chart.yaml` (helmv3)
* `package.json` (npm)
### What to Expect
With your current configuration, Renovate will create 6 Pull Requests:
<details>
<summary>Update dependency @​bitnami/readme-generator-for-helm to v2.5.1</summary>
- Schedule: ["at any time"]
- Branch name: `renovate/bitnami-readme-generator-for-helm-2.x-lockfile`
- Merge into: `main`
- Upgrade [@bitnami/readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm) to `2.5.1`
</details>
<details>
<summary>Update dependency markdownlint-cli to ^0.35.0</summary>
- Schedule: ["at any time"]
- Branch name: `renovate/markdownlint-cli-0.x`
- Merge into: `main`
- Upgrade [markdownlint-cli](https://github.com/igorshubovych/markdownlint-cli) to `^0.35.0`
</details>
<details>
<summary>Update postgresql Docker tag to v12.10.0</summary>
- Schedule: ["at any time"]
- Branch name: `renovate/postgresql-12.x`
- Merge into: `main`
- Upgrade postgresql to `12.10.0`
</details>
<details>
<summary>Update postgresql-ha Docker tag to v11.9.0</summary>
- Schedule: ["at any time"]
- Branch name: `renovate/postgresql-ha-11.x`
- Merge into: `main`
- Upgrade postgresql-ha to `11.9.0`
</details>
<details>
<summary>Update redis-cluster Docker tag to v8.8.2</summary>
- Schedule: ["at any time"]
- Branch name: `renovate/redis-cluster-8.x`
- Merge into: `main`
- Upgrade redis-cluster to `8.8.2`
</details>
<details>
<summary>Update redis-cluster Docker tag to v9</summary>
- Schedule: ["at any time"]
- Branch name: `renovate/redis-cluster-9.x`
- Merge into: `main`
- Upgrade redis-cluster to `9.0.1`
</details>
<br />
🚸 Branch creation will be limited to maximum 2 per hour, so it doesn't swamp any CI resources or overwhelm the project. See docs for `prhourlylimit` for details.
---
❓ Got questions? Check out Renovate's [Docs](https://docs.renovatebot.com/), particularly the Getting Started section.
If you need any further assistance then you can also [request help here](https://github.com/renovatebot/renovate/discussions).
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/492
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
### Description of the change
Before only `postgresql-ha` was auto-configured WRT to DNS.
### Benefits
Add DNS auto-config for `postgresql` dependency and assert that either `postgresql` or `postgresql-ha` is enabled.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/478
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
### Description of the change
Update default params of chart dependencies. Tested with multiple upgrades and fresh installations.
Using no password auth for redis simplifies things for basic installations. Production installations should properly configure auth as they need it.
### Benefits
To avoid/solve upgrading issues as in #407 and #472
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/473
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.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. -->
remove deployment, `serviceName`
### 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#466
### 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.] -->
- [x] 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)
- [x] Breaking changes are documented in the `README.md`
- [x] Templating unittests are added
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/467
Co-authored-by: yinheli <me@yinheli.com>
Co-committed-by: yinheli <me@yinheli.com>
# Changes
A big shoutout to @luhahn for all his work in #205 which served as the base for this PR.
## Documentation
- [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long).
Most of the information below should go into it with more details and explanations behind all of the individual components.
## Chart deps
~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~
~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~
- Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2.
- Removes `memcached` instead of `redis-cluster`
- Add `postgresql-ha` as default DB dep in favor of `postgres`
## Adds smart HA chart logic
The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1.
- If `replicaCount` > 1,
- `gitea.config.session.PROVIDER` is automatically set to `redis-cluster`
- `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch`
- `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not
Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc.
## Deployment vs Statefulset
Given all the discussions about this lately (#428), I think we could use both.
In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets.
On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment.
Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption.
Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case.
This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet.
The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way?
## Chart PVC Creation
I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation.
In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial.
A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse...
- New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim`
- New `persistence.create`: whether to create a new PVC
## Testing
As this PR does a lot of things, we need proper testing.
The helm chart can be installed from the Git branch via `helm-git` as follows:
```
helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment
helm install gitea --version 0.0.0
```
It is **highly recommended** to test the chart in a dedicated namespace.
I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine.
I just did some basic operations though and we should do more niche testing before merging.
Examplary `values.yml` for testing (only needs a valid RWX storage class):
<details>
<summary>values.yaml</summary>
```yml
image:
tag: "dev"
PullPolicy: "Always"
rootless: true
replicaCount: 2
persistence:
enabled: true
accessModes:
- ReadWriteMany
storageClass: FIXME
redis-cluster:
enabled: false
global:
redis:
password: gitea
gitea:
config:
indexer:
ISSUE_INDEXER_ENABLED: true
REPO_INDEXER_ENABLED: false
```
</details>
## Preferred setup
The preferred HA setup with respect to performance and stability might currently be as follows:
- Repos: RWX (e.g. EFS or Azurefiles NFS)
- Issue indexer: Meilisearch (HA)
- Session and cache: Redis Cluster (HA)
- Attachments/Avatars: Minio (HA)
This will result in a ~ 10-pod HA setup overall.
All pods have very low resource requests.
fix#98
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.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
Add documentation how to add custom themes
### 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#301
### 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. -->
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] 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)
- [x] Breaking changes are documented in the `README.md`
- [x] Templating unittests are added
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/460
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
### Description of the change
- Add ToC to README for easier navigation (and add note to `contributing.md`)
- Fix some heading levels in README
- Put upgrading notes into collapsible blocks
- Format `contributing.md` according to MD rules
- Allow `details` and `summary` elements in README
- Allow for longer headings
### Benefits
Better documentation
### Possible drawbacks
None
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/461
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
### Description of the change
This adds a new values object `serviceAccount`, that allows creating a dedicated ServiceAccount with the Helm Release into the cluster. It supports all common options like labels, annotations, name override (or referring to an externally created ServiceAccount), auto-mount token, image pull secrets.
It supersedes the stale PR #357.
### Benefits
Users can deploy Gitea with more fine-tuned security settings.
### Applicable issues
- related to #448
### Additional information
I've bumped the helm-unittest plugin in the CI build, to be able to use the `exists` and `notExists` feature in the new tests.
### Checklist
- [x] 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)
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/451
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Signed-off-by: Cyril Jouve <jv.cyril@gmail.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. -->
add a new value `extraDeploy` to add arbitrary resources
inspired by bitnami charts ([example](https://github.com/bitnami/charts/blob/main/bitnami/postgresql/values.yaml#L58)
### Benefits
<!-- What benefits will be realized by the code change? -->
with the change, I can deploy additional resources and keep them consistent with the chart (reuse macro, same labels, etc)., same workflow (helm upgrade), etc
### Possible drawbacks
<!-- Describe any known limitations with your change -->
### 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. -->
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] 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)
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/441
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: Cyril Jouve <jv.cyril@gmail.com>
Co-committed-by: Cyril Jouve <jv.cyril@gmail.com>
### Description of the change
Fix a wrong reference to `signing.existingKey`, `signing.existingSecret` was what was meant and what is used in the chart.
### Benefits
Less confusion when trying to use the Helm chart.
### Possible drawbacks
Evangelists of `existingKey` storming the barricades even though `existingKey` is long dead.
### Applicable issues
None, nobody noticed enough to care, apparently.
Co-authored-by: Tobias Wolter <towo@towo.eu>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/415
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: towo <towo@noreply.gitea.io>
Co-committed-by: towo <towo@noreply.gitea.io>
### Description of the change
Corrects the spelling of the word deprecated.
### Benefits
Documentation free of misspelled words is more likely to be viewed as "professional".
### Possible drawbacks
None that I can think of
### Applicable issues
- fixes#393
### Additional information
There may be other misspelled words or incorrectly phrased passages that aren't addressed in this PR.
For reference, see the online dictionary for the correct spelling of deprecated.
https://www.merriam-webster.com/dictionary/deprecated
### Checklist
- [X] 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)
- [X] Breaking changes are documented in the `README.md`
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/394
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: robv89r <robv8r@noreply.gitea.io>
Co-committed-by: robv89r <robv8r@noreply.gitea.io>
<!--
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
Exluding non helm chart related files from release artifact
### Benefits
Smaller release artifacts
### Possible drawbacks
Exluded files not visible any within the artifact
### Applicable issues
None
### Additional information
None
### ⚠ BREAKING
None
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] 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)
- [x] Breaking changes are documented in the `README.md`
Co-authored-by: Julian Schlarb <js@project-deadline.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/385
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Co-authored-by: JSchlarb <jschlarb@noreply.gitea.io>
Co-committed-by: JSchlarb <jschlarb@noreply.gitea.io>
### Description of the change
This PR adds support for gpg key setup. It allows to pass the gpg private key content inline inside `values.yaml` or refer to an existing secret containing the key content data.
### Benefits
Administrators don't need to manually setup the gpg environment from inside a running container. It also eliminates the breaking change of Gitea 1.17 regarding `[git].HOME` as the `GNUPGHOME` environment variable is used consistently to relocate the `.gnupg` directory to its former location.
### Applicable issues
- fixes#107
### Additional information
This PR add the first unit tests to this Helm Chart, ensuring templating integrity for signing related configuration.
### Checklist
- [x] 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)
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/343
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
### Description of the change
Checking the existence of the config directory should be done with the directory path itself. Not its parent directory.
This simple fix addresses that by using the config directory for its existence check.
### Benefits
Prior to #337 there was no other way to install this helm chart using the `extraVolumeMounts` setting with these values:
```yaml
replicaCount: %d
extraVolumes:
- name: config-volume
configMap:
name: %s
extraVolumeMounts:
- name: config-volume
mountPath: /data/gitea/templates/custom
```
Without this fix, the Gitea pod would never initialize, and would crashloop with the same error in #296.
### Additional information
Mounting a configMap to `/data/gitea/templates/custom` causes the `/data/gitea` folder to exist even though the `/data/gitea/conf` had not been initialized yet. The initialization script saw that the `/data/gitea` dir existed and exited early without initializing `/data/gitea/conf`.
Co-authored-by: cboin1996 <christianboin@hotmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/310
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Co-authored-by: cboin1996 <cboin1996@noreply.gitea.io>
Co-committed-by: cboin1996 <cboin1996@noreply.gitea.io>
Description of the change
Mostly, this change just moves the changelog to the bottom of the README which helps new users to see the actual documentation. As the structure for the changes itself is slightly different, there are some changes in wording so that it still makes sense. But mostly structural changes.
The change within the dependency section is due to a broken link since auto-generating the parameters section. Now there are links to every dependency related parameters.
Benefits
It helps us to maintain a clear structure for the README of this project.
Possible drawbacks
Our users are currently trained to look at the top of the document to see the changes. They now have to scroll down or use the quick link from installation section.
Applicable issues
fixes#247
Additional information
Every version section starts with a disclaimer right now. This is duplicated and might hide important text due to its existence. A centralized intruduction at top of the upgrading section tells the reader what to expect from that whole section.
I've also noticed that on ArtifactHub the emotes are not rendered correctly. So I replaced them with the actual ones and reduced their usage. That way it better highlights those parts the reader must not miss.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/331
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
## Context
PR #259 introduced support for running Gitea as a uid different than 1000 (git) or 0 (root).
## Problem
In init_directory_structure.sh, there is a "chown 1000:1000" on /tmp/gitea.
This chown only works when running as root or when the target directory is already owned by uid 1000.
As a result, the init container "init-directories" fails on startup when running Gitea with a uid different from 0 or 1000.
Initially, I worked around it by implementing an "initPreScript". But it would make user's life easier if we can make it work out-of-the-box.
## Resolution
I'm taking model on the chown a few lines above that depends on the value of image.rootless. Since the chown only works on default (root) image and is useless on rootless image, there is no need to run it on rootless image.
Co-authored-by: Nicolas MASSE <nicolas.masse@itix.fr>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/266
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
Co-committed-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
With release 5.0.0 there are so many deprecations and breaking changes
that it is probably a good way to assist the users with values migration
before breaking their environments.
This adds another template file that doesn't render anything but ensures
the removal of dropped or deprecated settings from customized values
files.
For when it is necessary, this check can be disabled via new setting
`checkDeprecation`.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/269
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: wxiaoguang <wxiaoguang@noreply.gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
With the result of PR #239 it is much easier to provide additional values to the _app.ini_ configuration from different sources.
These changes adds an _additionalConfigSources_ field where the users can define such sources. This enables the users to choose
on their own whether to store values in _values.yaml_ or load them from Kuberetes Secrets or ConfigMaps.
- Fixes#243
- Fixes#174
- Fixes#260
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/240
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: wxiaoguang <wxiaoguang@noreply.gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Hello !
I'm using the new Helm chart (5.x) and I really like the new configuration mechanism. 👍
I would like to contribute the following enhancement.
## The problem I want to solve
I'm trying to deploy Gitea in a Kubernetes shared platform and I need to make sure each instance is running as a different user so that in case of container escape, the risk of data leak is minimized.
Additionally, on my platform (OpenShift), arbitrary users (such as uid 1000 for Gitea) are not allowed.
The current helm chart does not allow me to achieve this because:
- the container security context is configurable only for the main container. The security context of init containers cannot be specified.
- a fixed uid is hard coded
- a fixed fs group is hard coded
Also, the securityContext of a pod and the securityContext of a container do not accept the same options.
- https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#podsecuritycontext-v1-core
- https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#securitycontext-v1-core
## How I'm solving the problem
I split the `securityContext` (values.yaml) in two: `containerSecurityContext` and `podSecurityContext`. The containerSecurityContext applies to all containers (init and main) in order to be consistent with file permissions.
The behavior for existing deployments is unchanged:
- fsGroup 1000 is the default value for the podSecurityContext variable
- the "configure-gitea" init container uses the uid 1000 unless otherwise stated in the containerSecurityContext
- the main container is using the existing securityContext variable when defined in order not to break existing deployments and uses the new containerSecurityContext variable if not.
This approach is well tested: it is used consistently on bitnami's Helm charts.
## How I tested
I tested both root and rootless variants on a Kubernetes 1.22, as well as rootless variant on OpenShift 4.7.
**rootless variant on Kubernetes**:
```yaml
podSecurityContext:
fsGroup: 10001
containerSecurityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
add:
- SYS_CHROOT
privileged: false
runAsGroup: 10001
runAsNonRoot: true
runAsUser: 10001
extraVolumes:
- name: var-lib-gitea
emptyDir: {}
extraVolumeMounts:
- name: var-lib-gitea
readOnly: false
mountPath: "/var/lib/gitea"
```
**rootless variant on OpenShift**:
```yaml
podSecurityContext:
fsGroup: null
containerSecurityContext:
allowPrivilegeEscalation: false
privileged: false
runAsNonRoot: true
runAsUser: 1000790000
extraVolumes:
- name: var-lib-gitea
emptyDir: {}
extraVolumeMounts:
- name: var-lib-gitea
readOnly: false
mountPath: "/var/lib/gitea"
```
Let me know if something is unclear.
Co-authored-by: Nicolas MASSE <nicolas.masse@itix.fr>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/259
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
Co-committed-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
Currently there are two different styles for defining both ldap and oauth configuration in _values.yaml_ file: `camelCase` and `kebab-case`.
Supporting both styles created multiple regressions in the past.
⚠️ BREAKING ⚠️
---------------
These changes completely remove any support for `kebab-case` notation in _values.yaml_ in favor of `camelCase`. Configuration keys must use `camelCase`.
Only exception are Kubernetes resource keys for annotations or labels.
Fixes: #188
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/196
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
These changes rewrite the init script to be error aware, informative and have a bit more security awareness.
During rewrite several hidden bugs could be identified and fixed, such as:
- LDAP configuration options interpreted by the shell before passed to command
- Finding multiple ldap ids instead of one during lookup when their names are almost identical
e.g. `_my-ldap-auth` and `my-ldap-auth`
- Properly filter auth sources by their types to prevent unintended type converting attempts that fail
In addition to that the script is a bit cleaner. Some commands do not exist anymore and would cause false-positive errors during script execution.
Helps for: #149
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/178
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
The `HOME` path is not persistent when using the rootless image, so the
`.gnupg` folder isn't either. Since the chart always used `/data/...` as
mount point for storage of all kinds, it is a minimal impact to just
relocate the dynamic `$HOME/.gnupg` folder location to the persistent
`/data/git/.gnupg`. This is where the signing keys are stored when
running root based environments. Doing so will
- allow migrations between both image variants
- persist signing keys for rootless environments
Fixes: #155
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/186
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
I've noticed that the commented `securityContext` is not really useable with the rootless image due to different directory structure compared to the default image.
Important for the `readOnlyRootFilesystem` is to declare the `TMPDIR` environment variable, so that the tmp directory (which is readonly in this case) won't be used. Instead, another writeable directory can be used.
Another thing is the explicit hint that all these security options cannot be used with the default (root-based) image, because of its design.
~~Although this PR would fix the referenced issue, I am not totally happy with the current implementation. It would be more straight forward to use the same mount points for both image variants. Unfortunately, this is not possible right now due to hard coded paths in the default (root) image startup scripts.~~
~~Anyone have suggestions on how this could be more simple?~~
-------
**Sum-up:**
As mentioned in Discord, this PR tried to make too many changes. The necessary changes made in 1f331a7e6577fc798196a84a957330aca0d663cd will fix an error that occurs due to restricted access to the `/tmp` directory in a rootless image with all the `securityContext` options enabled.
I also updated the default image to 1.14.2.
Fixes: #158
Co-authored-by: JustusBunsi <sk.bunsenbrenner@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/160
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: 6543 <6543@obermui.de>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
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
Kubernetes Helm chart for deploying [Gitea](https://gitea.com). Uses Go/Helm templating (`templates/`), YAML values (`values.yaml`), and includes sub-charts for PostgreSQL, PostgreSQL-HA, Valkey, and Valkey-cluster.
## Build & Test
```bash
make missing-dot # Check if the @param annotations are missing a trailing dot.
make readme # Regenerate README.md parameter table + lint + link checker
make helm/unittest # Run Helm unit tests (helm-unittest plugin required)
make bash/unittest # Run bash/bats script tests (requires git submodule init)
```
Always run `make readme` after changing `values.yaml``@param` annotations.
Always run `make helm/unittest` after changing templates or unit tests.
## Conventions
### values.yaml
- Use `## @param path.to.key Description` annotations for every user-facing value. These drive the auto-generated README parameter table.
- Property ordering within a resource block: `enabled`, `annotations`, `labels` first, then type-specific fields.
- Top-level keys are sorted alphabetically within their section group.
- Use [Helm Values](https://docs.renovatebot.com/modules/manager/helm-values/#additional-information) pattern from renovatebot. Ensure that the attributes `registry`, `repository` and `tag` are available as part of the dict `image`. For example:
```yaml
image:
registry:docker.io
repository:library/busybox
tag:0.1.0
```
### Templates
- Helm templates live in `templates/gitea/`. Helpers live in `templates/_helpers.tpl`.
- Use camelCase for all files and variables (e.g `httpRoute`, `backendTLSPolicy`, `gatewayAPI`, `statefulSet`).
- Use `include "gitea.fullname"` for naming resources.
- Use `fail` for required-value validation with clear error messages referencing the full values path.
- Ensure, that the attributes `annotations`, `labels`, `name` and `namespace` are alphabetically sorted.
- Render all attributes, even if they are empty, to prevent drift in Argo CD. For example, `labels` must be rendered, while `annotations` are defined as `yaml:"annotations,omitempty"`.
- Use plural for `*.tpl` files, because they may contain functions for multiple resources of the same kind (e.g. `_services.tpl` for `httpService.yaml` or `sshService.yaml`, `_backendTLSPolicies.tpl` for `backendTLSPolicy.yaml`).
- Use as prefix of YAML files the resource kind (e.g., `deployment.yaml` for `Deployment` resources). If there are multiple resources of the same kind, use a descriptive suffix (e.g., `deployment_metrics.yaml` for a `Deployment` related to metrics).
- Short names like `pvc` for Persistent Volume Claims or `svc` for Services are not allowed in file names or key names.
### Unit Tests
- Helm unit tests live in `unittests/helm/` mirroring the template structure.
- Test files are YAML using the [helm-unittest](https://github.com/helm-unittest/helm-unittest) format.
- Each test must set all required values explicitly — do not rely on cross-test state.
- The `values.yaml` file must pass `yamllint`. The configuration is in `.yamllint.yaml`. Use `make yamllint` to run the linter.
- The title of the unit test should clearly describe the scenario being tested. As title must be use a short sentence starting with a capital letter and ending without a period.
- Each unit test must explicitly set a custom namespace and release name, rather than relying on defaults.
### Commits & PRs
- Follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) for PR titles and commit messages (e.g. `feat:`, `fix:`, `refactor:`, `docs:`, `style:`).
- See `CONTRIBUTING.md` for full PR requirements.
- Explain in detail why a change is needed, not just what the change is. Include links to relevant issues, PRs, or external references.
- Add co-authors for any contributions that are not your own. Use the `Co-authored-by:` trailer in the commit message.
Any type of contribution is welcome; from new features, bug fixes, tests,
refactorings for easier maintainability or documentation improvements.
## Development environment
- [`node`](https://nodejs.org/en/) at least current LTS
- [`helm`](https://helm.sh/docs/intro/install/)
-`make` is optional; you may call the commands directly
When using Visual Studio Code as IDE, a [ready-to-use profile](.vscode/) is available.
## Documentation Requirements
The `README.md` must include all configuration options.
The parameters section is generated by extracting the parameter annotations from the `values.yaml` file, by using [this tool](https://github.com/bitnami-labs/readme-generator-for-helm).
If changes were made on configuration options, run `make readme` to update the README file.
The ToC is created via the VSCode [Markdown All in One](https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one) extension which can/must also be used used to update it.
## Pull Request Requirements
When submitting or updating a PR:
- make sure it passes CI builds.
- do not make independent changes in one PR.
- try to avoid rebases. They make code reviews for large PRs and comments much harder.
- if applicable, use the PR template for a well-defined PR description.
- clearly mark breaking changes.
- format the PR title following the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/#specification) schema
## Local development & testing
For local development and testing of pull requests, the following workflow can
be used:
1. Install `minikube` and `helm`.
2. Start a `minikube` cluster via `minikube start`.
3. From the `gitea/helm-gitea` directory execute the following command.
This will install the dependencies listed in `Chart.yml` and deploy the current state of the helm chart found locally.
If you want to test a branch, make sure to switch to the respective branch first.
This chart can expose Gitea through [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/) resources
alongside (or instead of) the existing `Ingress` and OpenShift `Route` support. The following resources
are rendered:
-`HTTPRoute` — required for HTTP traffic
-`TCPRoute` — optional, typically for SSH (port 22)
-`BackendTLSPolicy` — optional, for encrypted backend traffic
-`ClientSettingsPolicy` — optional, **NGINX Gateway Fabric only**, to raise the client request body size limit
All resources are disabled by default. Enabling them requires Gateway API CRDs (and an implementation that supports them) to already be installed in the cluster.
The chart does **not** render a `Gateway` resource — provisioning and managing the Gateway is the responsibility of the cluster / platform administrator.
## Prerequisites
| Resource | API version | Status (as of writing) |
maxSize:100m # bytes, or with a k / m / g suffix; 0 disables the limit
```
This renders a single `ClientSettingsPolicy` whose `targetRef` defaults to the chart's `HTTPRoute`
(`<fullname>`), so the limit applies to all traffic routed to Gitea. `body` is required when enabled; the
template fails fast if omitted. `spec.body` is passed through verbatim, so other fields (e.g. `timeout`)
are supported too.
To attach the policy elsewhere — for example the whole `Gateway` so the limit is inherited by every route —
override `targetRef`:
```yaml
gatewayAPI:
nginx:
clientSettingsPolicies:
enabled:true
targetRef:
group:gateway.networking.k8s.io
kind:Gateway
name:shared-gateway
body:
maxSize:100m
```
Notes:
-`ClientSettingsPolicy` is an inherited policy: attaching it to a `Gateway` cascades to its routes, while
attaching it to an `HTTPRoute` scopes it to that route only.
- The policy must live in the same namespace as its `targetRef`.
- Gitea also enforces its own upload limits independently (`gitea.config``[repository.upload]` and
`[packages]` sections) — raising the proxy limit alone is not always sufficient.
## Interaction with `ingress` and `route`
The three exposure mechanisms are independent and can coexist, but `ROOT_URL` / `DOMAIN` / `SSH_DOMAIN` resolution uses the first defined source in this order:
Likewise, `ROOT_URL` becomes `https://` if any of these terminate TLS: `route.tls.termination`, `ingress.tls`, or `gatewayAPI.core.httpRoute.tls`.
## SSH considerations
-`TCPRoute` is GA since Gateway API v1.4. Older CRD bundles only ship the `v1alpha2` version, so make sure the installed CRDs are at least v1.4.
- If your Gateway implementation does not support `TCPRoute`, keep using `service.ssh.type: LoadBalancer` (or `NodePort`) and only enable `httpRoute` for HTTP traffic.
- The default TCPRoute rule points at the Gitea SSH `Service` on `service.ssh.port` (typically 22), which itself proxies to `gitea.config.server.SSH_LISTEN_PORT` inside the pod.
All components (in-memory DB, volume/asset storage, code indexer) used by Gitea must be deployed in a HA-ready fashion to achieve a full HA-ready Gitea deployment.
The following document explains how to achieve this for all individual components.
The resulting Gitea deployment will consist of ~ 10 pods (depending on the chosen components and their replicas).
One should evaluate upfront whether a HA-deployment is required as switching between HA/non-HA comes with some effort.
For production instances, HA is always recommended to increase uptime and have a frictionless update process.
A general comment about chart dependencies and external services:
Instead of relying on chart dependencies, it is often better to rely on an external, (managed) instances (in-memory database, asset storage provider, database, etc.).
Many cloud providers offer such services, at least for databases or in-memory databases.
They might cost a bit more than using a self-hosted k8s variant but are usually easier to maintain and scale, if needed.
Also they can be centrally managed and are not linked to the Gitea helm chart or namespace.
Please consider using external services before you start with your Gitea HA setup, it will make your life (and the life of the Gitea maintainers) easier.
This helm chart tries to help as much as possible to simplify and assert the provisioning of a HA-ready Gitea instance by implementing smart conditionals if `deployment.replicas` is set to a value > 1.
Nevertheless, we cannot guarantee for every possible combination of Gitea settings to work together perfectly in a HA setup.
As a general advice, we recommend to have a test environment aside on which to test possible changes/upgrades before applying these to a production installation.
## Requirements for HA
Storage-wise, the HA-Gitea setup requires a RWX file-system which can be shared among the deployment-based replica pods.
In addition, the following components are required for full HA-readiness:
- A HA-ready issue (and optionally code) indexer: `elasticsearch` or `meilisearch`
- A HA-ready external object/asset storage (`minio`) (optional, assets can also be stored on the RWX file-system)
- A HA-ready cache (`valkey-cluster`)
- A HA-ready DB
`postgres.enabled`, which default to `true`, must be set to `false` for a HA setup.
The default `postgres` chart dependency is not HA-ready (there's a dedicated `postgres-ha` chart).
The following sections discuss each of the components in more detail.
Note that for each component discussed, the shown configurations only provides a (working) starting point, not necessarily the most optimal setup.
We try to optimize this document over time as we have gained more experience with HA setups from users.
## Indexers (Issues and code/repo)
The default code indexer `bleve` is not able to allow multiple connections and hence cannot be used in a HA setup.
Alternatives are `elasticsearch` and `meilisearch` (as of >= 1.19.2).
Unless you have an existing `elasticsearch` cluster, we recommend using `meilisearch` as it is faster and requires way less resources.
Unfortunately, `meilisearch` does only support the `ISSUE_INDEXER` and not the `REPO_INDEXER` yet ([tracking issue](https://github.com/go-gitea/gitea/pull/24149)).
This means that the `REPO_INDEXER` must still be disabled for a HA setup right now.
An alternative to the two options above for the `ISSUE_INDEXER` is `"db"`, however we recommend to just go with `meilisearch` in this case and to not bother the DB with indexing.
To configure `meilisearch` within Gitea, do the following:
By default, the `valkey-cluster` chart provisions three standalone master nodes of which each has a single replica.
To reduce the number of pods for a default Gitea deployment, we opted to omit the replicas (`replicas: 0`) by default.
Only the minimum required number of master pods for a functional `valkey-cluster` deployment are provisioned.
For a "proper" `valkey-cluster` setup however, we recommend to set `replicas: 1` and `nodes: 6`.
## Object and asset storage
Object/asset storage refers to the storage of attachments, avatars, LFS files, etc.
While most of these can be stored on the RWX file-system, it is recommended to use an external S3-compatible object storage for such, mainly for performance reasons.
By default the chart provisions a single RWO volume to store everything (repos, avatars, packages, etc.).
This volume cannot be mounted by multiple pods.
Hence, a RWX volume is required and (optionally) an external HA-ready object storage.
> **Note:** Double-check that the file permissions are set correctly on the RWX volume! That is everything should be owned by the `git` user which usually has `uid=1000` and `gid=1000`.
To use `minio` you need to deploy and configure an external `minio` instance yourself and explicitly define the `STORAGE_TYPE` values as shown below.
Note that `MINIO_BUCKET` here is just a name and does not refer to a S3 bucket.
It's the root access point for all objects belonging to the respective application, i.e., to Gitea in this case.
{{- if eq (get .Values.gitea.config.cache "ADAPTER") "memory" -}}
{{- $warnings = append $warnings "Gitea uses 'memory' for caching which is not recommended for production use. See https://docs.gitea.com/next/administration/config-cheat-sheet#cache-cache for available options." -}}
{{- end }}
{{- if eq (get .Values.gitea.config.queue "TYPE") "level" -}}
{{- $warnings = append $warnings "Gitea uses 'leveldb' for queue actions which is not recommended for production use. See https://docs.gitea.com/next/administration/config-cheat-sheet#queue-queue-and-queue for available options." -}}
{{- end }}
{{- if eq (get .Values.gitea.config.session "PROVIDER") "memory" -}}
{{- $warnings = append $warnings "Gitea uses 'memory' for sessions which is not recommended for production use. See https://docs.gitea.com/next/administration/config-cheat-sheet#session-session for available options." -}}
{{required"`secrets.admin.existingSecret.secretName` must be set when `secrets.admin.existingSecret.enabled` is enabled".Values.secrets.admin.existingSecret.secretName}}
{{required"`secrets.config.existingSecret.secretName` must be set when `secrets.config.existingSecret.enabled` is enabled".Values.secrets.config.existingSecret.secretName}}
{{required"`secrets.gpg.existingSecret.secretName` must be set when `secrets.gpg.existingSecret.enabled` is enabled".Values.secrets.gpg.existingSecret.secretName}}
{{required"`secrets.init.existingSecret.secretName` must be set when `secrets.init.existingSecret.enabled` is enabled".Values.secrets.init.existingSecret.secretName}}
{{required"`secrets.inlineConfig.existingSecret.secretName` must be set when `secrets.inlineConfig.existingSecret.enabled` is enabled".Values.secrets.inlineConfig.existingSecret.secretName}}
{{required"`secrets.metrics.existingSecret.secretName` must be set when `secrets.metrics.existingSecret.enabled` is enabled".Values.secrets.metrics.existingSecret.secretName}}
{{printf"`secrets.admin.passwordMode` must be set to one of 'keepUpdated', 'initialOnlyNoReset', or 'initialOnlyRequireReset'. Received: '%s'".Values.secrets.admin.passwordMode|fail}}
{{- fail "`gitea.customLivenessProbe` does no longer exist. Please refer to the changelog and configure `gitea.livenessProbe` instead." -}}
{{- end -}}
{{- if .Values.gitea.customReadinessProbe -}}
{{- fail "`gitea.customReadinessProbe` does no longer exist. Please refer to the changelog and configure `gitea.readinessProbe` instead." -}}
{{- end -}}
{{- if .Values.gitea.customStartupProbe -}}
{{- fail "`gitea.customStartupProbe` does no longer exist. Please refer to the changelog and configure `gitea.startupProbe` instead." -}}
{{- end -}}
{{/* LDAP SOURCES */}}
{{- if kindIs "map" .Values.gitea.ldap -}}
{{- fail "You can configure multiple LDAP sources. Please refer to the changelog and switch `gitea.ldap` from object to array notation." -}}
{{- end -}}
{{/* OAUTH SOURCES */}}
{{- if kindIs "map" .Values.gitea.oauth -}}
{{- fail "You can configure multiple OAuth sources. Please refer to the changelog and switch `gitea.oauth` from object to array notation." -}}
{{- end -}}
{{/* BUILTIN */}}
{{- if .Values.gitea.cache -}}
{{- if .Values.gitea.cache.builtIn -}}
{{- fail "`gitea.cache.builtIn` does no longer exist. Please use `memcached` at root level instead." -}}
{{- end -}}
{{- end -}}
{{- if .Values.gitea.database -}}
{{- if .Values.gitea.database.builtIn -}}
{{- fail "`gitea.database.builtIn` does no longer exist. Builtin databases can be configured inside the dependencies itself. Please refer to the changelog." -}}
{{- end -}}
{{- end -}}
{{- if .Values.gitea.admin -}}
{{- fail "`gitea.admin` does no longer exist. Please refer to the changelog and configure `secrets.admin` instead." -}}
{{- end -}}
{{/* SIGNING */}}
{{- if .Values.signing -}}
{{- fail "`signing` does no longer exist. Please refer to the changelog and configure `secrets.gpg` instead." -}}
{{- end -}}
{{/* AFFINITY */}}
{{- if .Values.affinity -}}
{{- fail "`affinity` does no longer exist. Please refer to the changelog and configure `deployment.affinity` instead." -}}
{{- end -}}
{{/* CONTAINER SECURITY CONTEXT */}}
{{- if .Values.containerSecurityContext -}}
{{- fail "`containerSecurityContext` does no longer exist. Please refer to the changelog and configure `deployment.gitea.securityContext` instead." -}}
{{- end -}}
{{/* DEPLOYMENT ENV */}}
{{- if .Values.deployment.env -}}
{{- fail "`deployment.env` does no longer exist. Please refer to the changelog and configure `deployment.gitea.env` instead." -}}
{{- end -}}
{{/* DNS CONFIG */}}
{{- if .Values.dnsConfig -}}
{{- fail "`dnsConfig` does no longer exist. Please refer to the changelog and configure `deployment.dnsConfig` instead." -}}
{{- end -}}
{{/* EXTRA CONTAINER VOLUME MOUNTS */}}
{{- if .Values.extraContainerVolumeMounts -}}
{{- fail "`extraContainerVolumeMounts` does no longer exist. Please refer to the changelog and configure `deployment.gitea.volumeMounts` instead." -}}
{{- end -}}
{{/* EXTRA VOLUMES */}}
{{- if .Values.extraVolumes -}}
{{- fail "`extraVolumes` does no longer exist. Please refer to the changelog and configure `deployment.volumes` instead." -}}
{{- end -}}
{{/* NODE SELECTOR */}}
{{- if .Values.nodeSelector -}}
{{- fail "`nodeSelector` does no longer exist. Please refer to the changelog and configure `deployment.nodeSelector` instead." -}}
{{- end -}}
{{/* OPENSHIFT HOST USERS */}}
{{- if hasKey .Values.openshift "hostUsers" -}}
{{- fail "`openshift.hostUsers` does no longer exist. Please refer to the changelog and configure `deployment.hostUsers` instead." -}}
{{- end -}}
{{/* PRIORITY CLASS NAME */}}
{{- if .Values.priorityClassName -}}
{{- fail "`priorityClassName` does no longer exist. Please refer to the changelog and configure `deployment.priorityClassName` instead." -}}
{{- end -}}
{{/* POD SECURITY CONTEXT */}}
{{- if .Values.podSecurityContext -}}
{{- fail "`podSecurityContext` does no longer exist. Please refer to the changelog and configure `deployment.securityContext` instead." -}}
{{- end -}}
{{/* POST EXTRA INIT CONTAINERS */}}
{{- if .Values.postExtraInitContainers -}}
{{- fail "`postExtraInitContainers` does no longer exist. Please refer to the changelog and append an entry with a `container` key to `deployment.initContainers` instead." -}}
{{- end -}}
{{/* PRE EXTRA INIT CONTAINERS */}}
{{- if .Values.preExtraInitContainers -}}
{{- fail "`preExtraInitContainers` does no longer exist. Please refer to the changelog and prepend an entry with a `container` key to `deployment.initContainers` instead." -}}
{{- end -}}
{{/* RESOURCES */}}
{{- if .Values.resources -}}
{{- fail "`resources` does no longer exist. Please refer to the changelog and configure `deployment.gitea.resources` instead." -}}
{{- end -}}
{{/* REPLICA COUNT */}}
{{- if .Values.replicaCount -}}
{{- fail "`replicaCount` does no longer exist. Please refer to the changelog and configure `deployment.replicas` instead." -}}
{{- end -}}
{{/* SCHEDULER NAME */}}
{{- if .Values.schedulerName -}}
{{- fail "`schedulerName` does no longer exist. Please refer to the changelog and configure `deployment.schedulerName` instead." -}}
{{- end -}}
{{/* SECURITY CONTEXT */}}
{{- if .Values.securityContext -}}
{{- fail "`securityContext` does no longer exist. Please refer to the changelog and configure `deployment.securityContext` and `deployment.gitea.securityContext` instead." -}}
{{- end -}}
{{/* STRATEGY */}}
{{- if .Values.strategy -}}
{{- fail "`strategy` does no longer exist. Please refer to the changelog and configure `deployment.strategy` instead." -}}
{{- end -}}
{{/* TOLERATIONS */}}
{{- if .Values.tolerations -}}
{{- fail "`tolerations` does no longer exist. Please refer to the changelog and configure `deployment.tolerations` instead." -}}
{{- end -}}
{{/* TOPOLOGY SPREAD CONSTRAINTS */}}
{{- if .Values.topologySpreadConstraints -}}
{{- fail "`topologySpreadConstraints` does no longer exist. Please refer to the changelog and configure `deployment.topologySpreadConstraints` instead." -}}
{{- if and (.Values.secrets.admin.enabled) (not .Values.secrets.admin.existingSecret.enabled) -}}
{{- if or (empty .Values.secrets.admin.new.username) (empty .Values.secrets.admin.new.password) -}}
{{- fail "Either specify `secrets.admin.new.username` and `secrets.admin.new.password` or reference an existing Secret via `secrets.admin.existingSecret`" -}}
{{- end }}
apiVersion:v1
kind:Secret
metadata:
{{- with (include "gitea.secret.admin.annotations" .) }}
annotations:
{{- . | nindent 4 }}
{{- end }}
labels:
{{- include "gitea.secret.admin.labels" . | nindent 4 }}
{{- /*assert that only one PG dep is enabled */ -}}
{{- if and (.Values.postgresql.enabled) (index .Values "postgresql-ha" "enabled") -}}
{{- fail "Only one of postgresql or postgresql-ha can be enabled at the same time." -}}
{{- end }}
{{- /* multiple replicas assertions */ -}}
{{- if gt (.Values.deployment.replicas | int) 1 -}}
{{- if .Values.gitea.config.cron -}}
{{- if .Values.gitea.config.cron.GIT_GC_REPOS -}}
{{- if eq .Values.gitea.config.cron.GIT_GC_REPOS.ENABLED true -}}
{{fail "Invoking the garbage collector via CRON is not yet supported when running with multiple replicas. Please set 'gitea.config.cron.GIT_GC_REPOS.enabled = false'." }}
{{- end }}
{{- end }}
{{- end }}
{{- if eq (first .Values.persistence.accessModes) "ReadWriteOnce" -}}
{{- fail "When using multiple replicas, a RWX file system is required and persistence.accessModes[0] must be set to ReadWriteMany." -}}
{{- end }}
{{- if .Values.gitea.config.indexer -}}
{{- if eq .Values.gitea.config.indexer.ISSUE_INDEXER_TYPE "bleve" -}}
{{- fail "When using multiple replicas, the issue indexer (gitea.config.indexer.ISSUE_INDEXER_TYPE) must be set to a HA-ready provider such as 'meilisearch', 'elasticsearch' or 'db' (if the DB is HA-ready)." -}}
{{- end }}
{{- if .Values.gitea.config.indexer.REPO_INDEXER_TYPE -}}
{{- if eq .Values.gitea.config.indexer.REPO_INDEXER_TYPE "bleve" -}}
{{- if .Values.gitea.config.indexer.REPO_INDEXER_ENABLED -}}
{{- if eq .Values.gitea.config.indexer.REPO_INDEXER_ENABLED true -}}
{{- fail "When using multiple replicas, the repo indexer (gitea.config.indexer.REPO_INDEXER_TYPE) must be set to 'meilisearch' or 'elasticsearch' or disabled." -}}
{{- if and (.Values.gitea.metrics.enabled) (.Values.gitea.metrics.serviceMonitor.enabled) (.Values.gitea.metrics.token) (not .Values.secrets.metrics.existingSecret.enabled) -}}
apiVersion:v1
kind:Secret
metadata:
{{- with (include "gitea.secret.metrics.annotations" .) }}
annotations:
{{- . | nindent 4 }}
{{- end }}
labels:
{{- include "gitea.secret.metrics.labels" . | nindent 4 }}
errorMessage:Either specify `secrets.admin.new.username` and `secrets.admin.new.password` or reference an existing Secret via `secrets.admin.existingSecret`
- it:renders the secret specification with the default credentials
value:"Z2l0ZWEtcGFzc3dvcmQ="# postgresql-ha.postgresql.password is overwritten by postgresql-ha.global.postgresql.password and should not be referenced here
- it:"[postgresql-ha] pgpool.adminPassword is applied as expected"
- it:fails with multiple replicas and "GIT_GC_REPOS" enabled
template:templates/gitea/secret_config.yaml
set:
deployment:
replicas:2
persistence:
accessModes:
- ReadWriteMany
gitea:
config:
cron:
GIT_GC_REPOS:
ENABLED:true
asserts:
- failedTemplate:
errorMessage:"Invoking the garbage collector via CRON is not yet supported when running with multiple replicas. Please set 'gitea.config.cron.GIT_GC_REPOS.enabled = false'."
- it:fails with multiple replicas and RWX file system not set
template:templates/gitea/secret_config.yaml
set:
deployment:
replicas:2
asserts:
- failedTemplate:
errorMessage:"When using multiple replicas, a RWX file system is required and persistence.accessModes[0] must be set to ReadWriteMany."
- it:fails with multiple replicas and bleve issue indexer
template:templates/gitea/secret_config.yaml
set:
deployment:
replicas:2
persistence:
accessModes:
- ReadWriteMany
gitea:
config:
indexer:
ISSUE_INDEXER_TYPE:bleve
asserts:
- failedTemplate:
errorMessage:"When using multiple replicas, the issue indexer (gitea.config.indexer.ISSUE_INDEXER_TYPE) must be set to a HA-ready provider such as 'meilisearch', 'elasticsearch' or 'db' (if the DB is HA-ready)."
- it:fails with multiple replicas and bleve repo indexer
template:templates/gitea/secret_config.yaml
set:
deployment:
replicas:2
persistence:
accessModes:
- ReadWriteMany
gitea:
config:
indexer:
REPO_INDEXER_TYPE:bleve
REPO_INDEXER_ENABLED:true
asserts:
- failedTemplate:
errorMessage:"When using multiple replicas, the repo indexer (gitea.config.indexer.REPO_INDEXER_TYPE) must be set to 'meilisearch' or 'elasticsearch' or disabled."
- it:omits the admin environment when the admin user is disabled
template:templates/gitea/deployment.yaml
set:
secrets.admin.enabled:false
asserts:
- notContains:
path:spec.template.spec.initContainers[2].env
content:
name:GITEA_ADMIN_USERNAME
any:true
- notContains:
path:spec.template.spec.initContainers[2].env
content:
name:GITEA_ADMIN_PASSWORD_MODE
any:true
- it:fails on an unsupported password mode
template:templates/gitea/deployment.yaml
set:
secrets.admin.passwordMode:unsupported
asserts:
- failedTemplate:
errorMessage:"`secrets.admin.passwordMode` must be set to one of 'keepUpdated', 'initialOnlyNoReset', or 'initialOnlyRequireReset'. Received: 'unsupported'"
- it:fails when the removed `affinity` value is set
set:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key:kubernetes.io/os
operator:In
values:
- linux
asserts:
- failedTemplate:
errorMessage:"`affinity` does no longer exist. Please refer to the changelog and configure `deployment.affinity` instead."
- it:fails when the removed `containerSecurityContext` value is set
set:
containerSecurityContext:
runAsUser:1000
asserts:
- failedTemplate:
errorMessage:"`containerSecurityContext` does no longer exist. Please refer to the changelog and configure `deployment.gitea.securityContext` instead."
- it:fails when the removed `deployment.env` value is set
set:
deployment.env:
- name:VARIABLE
value:my-value
asserts:
- failedTemplate:
errorMessage:"`deployment.env` does no longer exist. Please refer to the changelog and configure `deployment.gitea.env` instead."
- it:fails when the removed `dnsConfig` value is set
set:
dnsConfig:
nameservers:
- 192.0.2.1
asserts:
- failedTemplate:
errorMessage:"`dnsConfig` does no longer exist. Please refer to the changelog and configure `deployment.dnsConfig` instead."
- it:fails when the removed `extraContainerVolumeMounts` value is set
set:
extraContainerVolumeMounts:
- name:postgres-ssl-vol
mountPath:/pg-ssl
asserts:
- failedTemplate:
errorMessage:"`extraContainerVolumeMounts` does no longer exist. Please refer to the changelog and configure `deployment.gitea.volumeMounts` instead."
- it:fails when the removed `extraVolumes` value is set
set:
extraVolumes:
- name:postgres-ssl-vol
secret:
secretName:gitea-postgres-ssl
asserts:
- failedTemplate:
errorMessage:"`extraVolumes` does no longer exist. Please refer to the changelog and configure `deployment.volumes` instead."
- it:fails when the removed `nodeSelector` value is set
set:
nodeSelector:
foo:bar
asserts:
- failedTemplate:
errorMessage:"`nodeSelector` does no longer exist. Please refer to the changelog and configure `deployment.nodeSelector` instead."
- it:fails when the removed `openshift.hostUsers` value is set
set:
openshift.hostUsers:false
asserts:
- failedTemplate:
errorMessage:"`openshift.hostUsers` does no longer exist. Please refer to the changelog and configure `deployment.hostUsers` instead."
- it:fails when the removed `priorityClassName` value is set
set:
priorityClassName:high-priority
asserts:
- failedTemplate:
errorMessage:"`priorityClassName` does no longer exist. Please refer to the changelog and configure `deployment.priorityClassName` instead."
- it:fails when the removed `podSecurityContext` value is set
set:
podSecurityContext:
fsGroup:1000
asserts:
- failedTemplate:
errorMessage:"`podSecurityContext` does no longer exist. Please refer to the changelog and configure `deployment.securityContext` instead."
- it:fails when the removed `postExtraInitContainers` value is set
set:
postExtraInitContainers:
- name:post-init-container
image:docker.io/library/busybox
asserts:
- failedTemplate:
errorMessage:"`postExtraInitContainers` does no longer exist. Please refer to the changelog and append an entry with a `container` key to `deployment.initContainers` instead."
- it:fails when the removed `preExtraInitContainers` value is set
set:
preExtraInitContainers:
- name:pre-init-container
image:docker.io/library/busybox
asserts:
- failedTemplate:
errorMessage:"`preExtraInitContainers` does no longer exist. Please refer to the changelog and prepend an entry with a `container` key to `deployment.initContainers` instead."
- it:fails when the removed `resources` value is set
set:
resources:
limits:
cpu:100m
asserts:
- failedTemplate:
errorMessage:"`resources` does no longer exist. Please refer to the changelog and configure `deployment.gitea.resources` instead."
- it:fails when the removed `replicaCount` value is set
set:
replicaCount:2
asserts:
- failedTemplate:
errorMessage:"`replicaCount` does no longer exist. Please refer to the changelog and configure `deployment.replicas` instead."
- it:fails when the removed `schedulerName` value is set
set:
schedulerName:stork
asserts:
- failedTemplate:
errorMessage:"`schedulerName` does no longer exist. Please refer to the changelog and configure `deployment.schedulerName` instead."
- it:fails when the removed `securityContext` value is set
set:
securityContext:
runAsUser:1000
asserts:
- failedTemplate:
errorMessage:"`securityContext` does no longer exist. Please refer to the changelog and configure `deployment.securityContext` and `deployment.gitea.securityContext` instead."
- it:fails when the removed `strategy` value is set
set:
strategy:
type:Recreate
asserts:
- failedTemplate:
errorMessage:"`strategy` does no longer exist. Please refer to the changelog and configure `deployment.strategy` instead."
- it:fails when the removed `tolerations` value is set
set:
tolerations:
- key:database/type
operator:Equal
value:postgres
effect:NoSchedule
asserts:
- failedTemplate:
errorMessage:"`tolerations` does no longer exist. Please refer to the changelog and configure `deployment.tolerations` instead."
- it:fails when the removed `topologySpreadConstraints` value is set
set:
topologySpreadConstraints:
- topologyKey:kubernetes.io/hostname
asserts:
- failedTemplate:
errorMessage:"`topologySpreadConstraints` does no longer exist. Please refer to the changelog and configure `deployment.topologySpreadConstraints` instead."
- it:skips the deprecation checks when `checkDeprecation` is disabled
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
volker.raschekandCopilot