ab24bcd9a57cbb776571fd5b051efc714e1574fd
54
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  volker.raschekandCopilot
|
ab24bcd9a5
|
feat(deployment)!: move extraVolumes and extraContainerVolumeMounts into the deployment dict
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> |
||
|
volker.raschekandCopilot
|
00ccfc6734
|
refactor!: remove the deprecated securityContext value
`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> |
||
|
volker.raschekandCopilot
|
377306b418
|
feat(deployment)!: move security contexts into the deployment dict
`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> |
||
|
volker.raschekandCopilot
|
3c9fc19829
|
feat(deployment)!: move image to deployment.gitea.image
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> |
||
|
volker.raschekandCopilot
|
f385d22b56
|
feat(deployment)!: move replicaCount to deployment.replicas
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> |
||
|
volker.raschekandCopilot
|
34dd14e3d8
|
feat(deployment)!: move strategy to deployment.strategy
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> |
||
|
volker.raschekandCopilot
|
80592de2d0
|
feat(deployment)!: move schedulerName to deployment.schedulerName
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> |
||
|
volker.raschekandCopilot
|
56119038ec
|
feat(deployment)!: move tolerations to deployment.tolerations
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> |
||
|
volker.raschekandCopilot
|
9e12eeccab
|
feat(deployment)!: move topologySpreadConstraints to deployment.topologySpreadConstraints
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> |
||
|
volker.raschekandCopilot
|
20de800294
|
feat(deployment)!: split resources into deployment.gitea.resources and deployment.resources
The top-level `resources` value was applied to the Gitea container only, while its name suggested it covered the whole pod. Kubernetes meanwhile supports pod-level resources, so a single ambiguous key can no longer express both scopes. Container-scoped limits and requests now live in `deployment.gitea.resources`, next to `deployment.gitea.env`, and the new `deployment.resources` maps to the pod-level `resources` field. The pod-level block is only rendered when set, because the field is not accepted by older API servers and would otherwise be rejected on clusters that do not support it yet. The GOMAXPROCS derivation follows the container-scoped value and tolerates an unset `deployment.gitea.resources`, which defaults to `null`. The `deployment` section marker in `values.yaml` is restored as well. Without it the generated README lost its `### deployment` heading and the manually maintained table of contents pointed at a non-existing anchor, which made `markdownlint` fail. BREAKING CHANGE: `resources` no longer exists. Use `deployment.gitea.resources` for container limits and requests, or `deployment.resources` for pod-level resources. Installations that still set `resources` will fail unless `checkDeprecation` is set to `false`. Co-authored-by: Copilot <copilot@github.com> |
||
|
volker.raschekandCopilot
|
25b3fff3eb
|
feat(deployment)!: move nodeSelector to deployment.nodeSelector
`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> |
||
|
volker.raschekandCopilot
|
9fb628f7db
|
feat(deployment)!: move dnsConfig to deployment.dnsConfig
`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> |
||
|
volker.raschekandCopilot
|
55964679ea
|
feat(deployment)!: move deployment.env to deployment.gitea.env and add deployment.enabled
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> |
||
|
volker.raschekandCopilot
|
150c08eabc
|
feat(deployment)!: move affinity to deployment.affinity
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> |
||
|
volker.raschekandCopilot
|
229ba12744
|
feat(secrets)!: replace the gitea.admin object with secrets.admin
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>
|
||
|
volker.raschekandCopilot
|
3535611d4d
|
feat(secrets)!: replace the signing object with secrets.gpg
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>
|
||
|
volker.raschekandCopilot
|
4d82f17ce6
|
feat(secrets): make every Secret configurable via a secrets.* block
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> |
||
|
volker.raschekandCopilot
|
a4c6893874
|
refactor(templates)!: centralize Secret names in gitea.secret.*.name helpers
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> |
||
|
volker.raschekandCopilot
|
4884dc0fe0
|
refactor(templates): rename template files to match rendered resource kinds
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> |
||
|
volker.raschek
|
bebe2a6009
|
[Close #1106] feat(gatewayAPI)!: migrate TCPRoute to gateway.networking.k8s.io/v1
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 |
||
|
volker.raschek
|
311cb9fe37
|
fix!: remove deprecated actions migration warning
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. |
||
|
|
407a7027bc |
fix(valkey)!: migrate to valkey/valkey (#1097)
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> |
||
|
volker.raschek
|
4f4bd4927c
|
test: add unit tests for custom clusterDomain in database connection strings
Verify that PostgreSQL and PostgreSQL-HA service hostnames correctly use a custom `clusterDomain` value instead of the default `cluster.local` when connecting to the database. |
||
|
volker.raschek
|
0d6085f68d
|
fix(valkey): respect cluster domain [Close #1091] | ||
|
Todd Marimon
|
7747a001f7 |
feat: add Gateway API support (#1073)
Add full Gateway API support for exposing Gitea via HTTPRoute, TCPRoute, BackendTLSPolicy, and ClientSettingsPolicy resources. New templates: - `httpRoute.yaml` — renders an HTTPRoute with configurable parentRefs, hostnames, and rules (defaults to PathPrefix `/`) - `tcpRoute.yaml` — renders a TCPRoute for SSH traffic - `backendTLSPolicy.yaml` — renders a BackendTLSPolicy for encrypted backend connections with required validation config - `clientSettingsPolicy.yaml` — renders an NGINX Gateway Fabric ClientSettingsPolicy to raise the request body size limit Infrastructure: - `gatewayAPI.enabled` global toggle gates all resources - Resources grouped under `gatewayAPI.core.*` and `gatewayAPI.nginx.*` - Helper templates extracted into dedicated `_*.tpl` files - Service name helpers (`gitea.service.http.name`, `gitea.service.ssh.name`) extracted into `_services.tpl`; service templates renamed to camelCase - `ROOT_URL`, `DOMAIN`, and `SSH_DOMAIN` auto-resolve from `httpRoute.hostnames[0]`; `httpRoute.tls` switches to `https` Documentation: - New `docs/gateway-api.md` with topology examples, BackendTLSPolicy setup, sectionName guidance, SSH considerations, and NGINX body size limit configuration - `.github/copilot-instructions.md` with project conventions - README parameter table auto-generated via `make readme` Tests: - Helm unit tests for all four new resource templates - Config tests for hostname/TLS resolution from Gateway API values Co-authored-by: Todd Marimon <toddmarimon@gmail.com> |
||
|
Lunny Xiao
|
1baf2d0656 |
chore(deps): upgrade to 1.26 and replace environment_to_ini_call with gitea config edit-ini (#1070)
Need more time to know how to handle `expect_environment_to_ini_call` Fix #1068 Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1070 Reviewed-by: Zettat123 <39446+zettat123@noreply.gitea.com> |
||
|
techknowlogick
|
682cfec590 | DNS handling fixes for init/bootstrap process | ||
|
techknowlogick
|
b7663bb95f | fix: Improve OpenShift compatibility (#1066) | ||
|
techknowlogickandLunny Xiao
|
a02a7feb6e |
feat: enhance openshift support (#1063)
### 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> |
||
|
deepakdeore2004andtechknowlogick
|
e673346bb8 |
Support to read environment variables from file in init containers (#993)
### 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>
|
||
|
Tarun Gaba
|
0d7368c5d0 |
fix(deployment): remove deployment.labels from selector.matchLabels (#1011)
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> |
||
|
volker.raschek
|
064e51d0c2
|
style(yamllint): add missing new line | ||
|
volker.raschek
|
b88abaa1e7
|
fix(deployment): avoid duplicated nodeSelector #980 | ||
|
volker.raschek
|
89017545d3 |
fix(deps): use bitnamilegacy images (#962)
The following PR overwrites the `registry`, `repository` and `tag` attributes of the dependencies to download the images from the `bitnamilegacy` repository. This allows us to redeploy the v12 release stream, even though we are no longer receiving updates for the bitnami images. Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/962 Reviewed-by: techknowlogick <techknowlogick@noreply.gitea.com> Co-authored-by: Markus Pesch <markus.pesch@cryptic.systems> Co-committed-by: Markus Pesch <markus.pesch@cryptic.systems> |
||
|
volker.raschek
|
10ad0f7743
|
style: adapt indentation of extraInitContainer tests | ||
|
kostovicmb
|
4cfcbd729f
|
feat(deployment): support further initContainers
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 ``` |
||
|
Jade Deane
|
aa7ccb47ba |
fix: add srCheckPassword param to support new postgresql-ha stream replication check requirements (#894)
### 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> |
||
|
pat-s
|
edc42f69a9 | fix: ingress unittests | ||
|
|
a94eec4238 |
refactor: migrate ingress definition out of beta (#679)
### 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> |
||
|
Sean Teoandpat-s
|
6e4e414771 |
chore(deps)!: Migrate to Valkey from Redis (#775)
<!-- 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> |
||
|
techknowlogickandChristopher Homberger
|
3b32a04b9c |
chore(actions): check actions is not configured (#849)
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> |
||
|
developerguy
|
a7035ca4e5 |
feat: make it configurable of the initContainers volume mount path for scripts (#848)
### Description of the change Makes it configurable volume mount path for initContainers for init scripts ### Benefits Configurable initContainers volumeMount path for init scripts ### Possible drawbacks I don't think that there will be any drawbacks ### Applicable issues - Fixes #847 Signed-off-by: Batuhan Apaydin <batuhan.apaydin@chainguard.dev> Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/848 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com> Co-authored-by: developerguy <developerguy@noreply.gitea.com> Co-committed-by: developerguy <developerguy@noreply.gitea.com> |
||
|
|
6c5b42c482 |
refactor!: remove actions related files (#825)
see #824 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/825 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> 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> |
||
|
|
1f313ac70e |
feat: adding dry support to gitea additional config from envs parameter (#840)
### Description of the change Based on the discussion under https://gitea.com/gitea/helm-gitea/issues/60, it is possible to use `gitea.additionalConfigFromEnvs` to provide variables in order to override configurations from `app.ini`. Especially when using gitea as a dependency of an umbrella, some values may need to be repeated in multiple places (such has database configuration). Hence, introducing the `tpl` function on `gitea.additionalConfigFromEnvs` will simplify such repetition by having the value only set in one place... ### Benefits With the same intentions as https://gitea.com/gitea/helm-gitea/pulls/759, https://gitea.com/gitea/helm-gitea/pulls/664, https://gitea.com/gitea/helm-gitea/pulls/529 or https://gitea.com/gitea/helm-gitea/pulls/498, this change will allow reusing the value from other value parameters to avoid duplicating the same value in multiple places. ### Possible drawbacks N/A ### Applicable issues N/A ### Additional information N/A ### Checklist - [X] Helm templating unittests are added (required when changing anything in `templates` folder) Co-authored-by: 212597596 <cedric.henry@ge.com> Co-authored-by: pat-s <pat-s@noreply.gitea.com> Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/840 Reviewed-by: pat-s <pat-s@noreply.gitea.com> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com> Co-authored-by: Ceddaerrix <ceddaerrix@noreply.gitea.com> Co-committed-by: Ceddaerrix <ceddaerrix@noreply.gitea.com> |
||
|
bachorpandtechknowlogick
|
2c78da9c3e |
docs: set full path of values.yaml key in output to user (#832)
generate-chart / generate-chart-publish (push) Has been cancelled
Currently, the reported path of the values to be changed is not always correct (especially `gitea.persistence` vs. `persistence`). Co-authored-by: techknowlogick <techknowlogick@noreply.gitea.com> Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/832 Reviewed-by: techknowlogick <techknowlogick@noreply.gitea.com> Co-authored-by: bachorp <bachorp@noreply.gitea.com> Co-committed-by: bachorp <bachorp@noreply.gitea.com> |
||
|
pat-sandtechknowlogick
|
7245b3b4cc |
chore: change repo name to helm-gitea (#823)
Co-authored-by: techknowlogick <techknowlogick@gitea.com> Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/823 Reviewed-by: techknowlogick <techknowlogick@noreply.gitea.com> 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> |
||
|
techknowlogick
|
ff7783fcbe |
chore: use docker.gitea.com registry URLs (#814)
Due to ratelimits Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/814 Reviewed-by: pat-s <pat-s@noreply.gitea.com> Co-authored-by: techknowlogick <techknowlogick@gitea.com> Co-committed-by: techknowlogick <techknowlogick@gitea.com> |
||
|
Renovate Botandpat-s
|
d8ec7dc2f5 |
chore(deps): update postgresql docker tag to v16 (#736)
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 | `15.5.38` -> `16.4.6` | --- ### Release Notes <details> <summary>bitnami/charts (postgresql)</summary> ### [`v16.4.6`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#1646-2025-02-02) - \[bitnami/postgresql] Release 16.4.6 ([#​31702](https://github.com/bitnami/charts/pull/31702)) ### [`v16.4.5`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1645-2025-01-20-small) - \[bitnami/postgresql] Release 16.4.5 ([#​31484](https://github.com/bitnami/charts/issues/31484)) ([b11637c](https://github.com/bitnami/charts/commit/b11637c36ab924cd764ead95e30838a0c4af8321)), closes [#​31484](https://github.com/bitnami/charts/issues/31484) ### [`v16.4.4`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1644-2025-01-20-small) - \[bitnami/postgresql] Release 16.4.4 ([#​31482](https://github.com/bitnami/charts/issues/31482)) ([e784f18](https://github.com/bitnami/charts/commit/e784f187c01d6a2d7a1237ae5015bd5cb6e4e4b8)), closes [#​31482](https://github.com/bitnami/charts/issues/31482) ### [`v16.4.3`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1643-2025-01-14-small) - bitnami/postgresql Fix missing dot in include statement for passwordUpdate job template ([#​31364](https://github.com/bitnami/charts/issues/31364)) ([901b26c](https://github.com/bitnami/charts/commit/901b26c4b7be8935d9764d51df4b76d8dede0117)), closes [#​31364](https://github.com/bitnami/charts/issues/31364) ### [`v16.4.2`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1642-2025-01-13-small) - \[bitnami/postgresql] Release 16.4.2 ([#​31342](https://github.com/bitnami/charts/issues/31342)) ([946b638](https://github.com/bitnami/charts/commit/946b638fd63e2d7e74865d591ef403b4dce229b3)), closes [#​31342](https://github.com/bitnami/charts/issues/31342) ### [`v16.4.1`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1641-2025-01-13-small) - Dynamic assignment of custom schema name if defined in update-password job ([#​31146](https://github.com/bitnami/charts/issues/31146)) ([364ac45](https://github.com/bitnami/charts/commit/364ac45ea6a20b693662b14a17122885f4e43364)), closes [#​31146](https://github.com/bitnami/charts/issues/31146) ### [`v16.3.5`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1635-2025-01-03-small) - Revert "\[bitnami/postgresql] Add Storage Class Configuration to Templates ([#​30858](https://github.com/bitnami/charts/issues/30858))" ([#​31204](https://github.com/bitnami/charts/issues/31204)) ([c03fe0c](https://github.com/bitnami/charts/commit/c03fe0c3e359db15c2c096d52e6e28e480dfdbd6)), closes [#​30858](https://github.com/bitnami/charts/issues/30858) [#​31204](https://github.com/bitnami/charts/issues/31204) ### [`v16.3.4`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1634-2024-12-23-small) - \[bitnami/postgresql] Release 16.3.4 ([#​31143](https://github.com/bitnami/charts/issues/31143)) ([05a9583](https://github.com/bitnami/charts/commit/05a9583f949b49fab2673774a4f56ff686d959f4)), closes [#​31143](https://github.com/bitnami/charts/issues/31143) ### [`v16.3.3`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1633-2024-12-20-small) - \[bitnami/postgresql] Release 16.3.3 ([#​31133](https://github.com/bitnami/charts/issues/31133)) ([41671f2](https://github.com/bitnami/charts/commit/41671f2e787863686079e1358054142d61d15982)), closes [#​31133](https://github.com/bitnami/charts/issues/31133) ### [`v16.3.2`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1632-2024-12-16-small) - \[bitnami/\*] Fix typo in README ([#​31052](https://github.com/bitnami/charts/issues/31052)) ([b41a51d](https://github.com/bitnami/charts/commit/b41a51d1bd04841fc108b78d3b8357a5292771c8)), closes [#​31052](https://github.com/bitnami/charts/issues/31052) - \[bitnami/postgresql] Release 16.3.2 ([#​31060](https://github.com/bitnami/charts/issues/31060)) ([1406ab1](https://github.com/bitnami/charts/commit/1406ab116e0fcfbb8fe2eaec1adc5fe494c0f329)), closes [#​31060](https://github.com/bitnami/charts/issues/31060) ### [`v16.3.1`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1631-2024-12-13-small) - \[bitnami/postgresql] Add Storage Class Configuration to Templates ([#​30858](https://github.com/bitnami/charts/issues/30858)) ([b0d2c2e](https://github.com/bitnami/charts/commit/b0d2c2e53c9033d3827597c561931fbb331eb99b)), closes [#​30858](https://github.com/bitnami/charts/issues/30858) ### [`v16.3.0`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#1630-2024-12-10) - \[bitnami/\*] Add Bitnami Premium to NOTES.txt ([#​30854](https://github.com/bitnami/charts/issues/30854)) ([3dfc003](https://github.com/bitnami/charts/commit/3dfc00376df6631f0ce54b8d440d477f6caa6186)), closes [#​30854](https://github.com/bitnami/charts/issues/30854) - \[bitnami/postgresql] Detect non-standard images ([#​30936](https://github.com/bitnami/charts/issues/30936)) ([ac96151](https://github.com/bitnami/charts/commit/ac96151bdbe5e99b00dcde62a4d72f1827fa46b2)), closes [#​30936](https://github.com/bitnami/charts/issues/30936) ### [`v16.2.5`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1625-2024-12-03-small) - \[bitnami/postgresql] Release 16.2.5 ([#​30733](https://github.com/bitnami/charts/issues/30733)) ([34606c1](https://github.com/bitnami/charts/commit/34606c10dedd06431182d0563fb61703e691ddf1)), closes [#​30733](https://github.com/bitnami/charts/issues/30733) ### [`v16.2.4`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1624-2024-12-03-small) - \[bitnami/\*] docs: 📝 Add "Backup & Restore" section ([#​30711](https://github.com/bitnami/charts/issues/30711)) ([35ab536](https://github.com/bitnami/charts/commit/35ab5363741e7548f4076f04da6e62d10153c60c)), closes [#​30711](https://github.com/bitnami/charts/issues/30711) - \[bitnami/\*] docs: 📝 Add "Prometheus metrics" (batch 5) ([#​30674](https://github.com/bitnami/charts/issues/30674)) ([ed2a546](https://github.com/bitnami/charts/commit/ed2a54617faf763169e6b01a89100b9db32e1000)), closes [#​30674](https://github.com/bitnami/charts/issues/30674) - \[bitnami/postgresql] use adminPassword for metrics user when custom user is not set ([#​30720](https://github.com/bitnami/charts/issues/30720)) ([8f4bc7b](https://github.com/bitnami/charts/commit/8f4bc7b46b0ce02286cc9973ff8f054a1f9c3fde)), closes [#​30720](https://github.com/bitnami/charts/issues/30720) ### [`v16.2.3`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1623-2024-11-28-small) - \[bitnami/postgresql] Release 16.2.3 ([#​30645](https://github.com/bitnami/charts/issues/30645)) ([22a4c51](https://github.com/bitnami/charts/commit/22a4c51dc3b85e73b017cb6f6c73e15e6e4b811c)), closes [#​30645](https://github.com/bitnami/charts/issues/30645) ### [`v16.2.2`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1622-2024-11-21-small) - \[bitnami/postgresql] Release 16.2.2 ([#​30570](https://github.com/bitnami/charts/issues/30570)) ([7b3a6d5](https://github.com/bitnami/charts/commit/7b3a6d5808e79d68a7c9edb6bca54aff262a6264)), closes [#​30570](https://github.com/bitnami/charts/issues/30570) ### [`v16.2.1`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1621-2024-11-14-small) - \[bitnami/postgresql] Release 16.2.1 ([#​30463](https://github.com/bitnami/charts/issues/30463)) ([2360527](https://github.com/bitnami/charts/commit/236052763a4d81ca42d1068203ce5d6ee3f61b20)), closes [#​30463](https://github.com/bitnami/charts/issues/30463) ### [`v16.2.0`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#1620-2024-11-14) - \[bitnami/postgresql] feat: ✨ Add password update job ([#​30444](https://github.com/bitnami/charts/issues/30444)) ([ea896db](https://github.com/bitnami/charts/commit/ea896dbfbfaf7d386ca40c4072a61aa958cb7fb1)), closes [#​30444](https://github.com/bitnami/charts/issues/30444) ### [`v16.1.2`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1612-2024-11-06-small) - \[bitnami/postgresql] Release 16.1.2 ([#​30250](https://github.com/bitnami/charts/issues/30250)) ([423c554](https://github.com/bitnami/charts/commit/423c55454743745dc486e426089141fa814fd401)), closes [#​30250](https://github.com/bitnami/charts/issues/30250) ### [`v16.1.1`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1611-2024-11-04-small) - \[bitnami/postgresql] metrics.collectors applies to read replicas ([#​30133](https://github.com/bitnami/charts/issues/30133)) ([696f113](https://github.com/bitnami/charts/commit/696f113b68a7f541de7f073cf3efec5b25ccf10b)), closes [#​30133](https://github.com/bitnami/charts/issues/30133) ### [`v16.1.0`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#1610-2024-10-30) - \[bitnami/\*] Remove wrong comment about imagePullPolicy ([#​30107](https://github.com/bitnami/charts/issues/30107)) ([a51f9e4](https://github.com/bitnami/charts/commit/a51f9e4bb0fbf77199512d35de7ac8abe055d026)), closes [#​30107](https://github.com/bitnami/charts/issues/30107) - \[bitnami/postgresql] Added support for `namespaceOverride` ([#​30113](https://github.com/bitnami/charts/issues/30113)) ([4253372](https://github.com/bitnami/charts/commit/4253372e0b770e941c4894cdd7a904d3fdabeb19)), closes [#​30113](https://github.com/bitnami/charts/issues/30113) ### [`v16.0.6`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1606-2024-10-24-small) - \[bitnami/postgresql] Release 16.0.6 ([#​30069](https://github.com/bitnami/charts/issues/30069)) ([e431b4a](https://github.com/bitnami/charts/commit/e431b4a915cb29593faedff990bba9516dc25ef6)), closes [#​30069](https://github.com/bitnami/charts/issues/30069) ### [`v16.0.5`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1605-2024-10-22-small) - \[bitnami/postgresql] Release 16.0.5 ([#​30046](https://github.com/bitnami/charts/issues/30046)) ([a825e37](https://github.com/bitnami/charts/commit/a825e37775f041dc3404f727ff33661364dbc8a3)), closes [#​30046](https://github.com/bitnami/charts/issues/30046) ### [`v16.0.4`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1604-2024-10-21-small) - \[bitnami/postgresql] Release 16.0.4 ([#​30013](https://github.com/bitnami/charts/issues/30013)) ([8435f88](https://github.com/bitnami/charts/commit/8435f88ae01cc20203022eb97904ee3abeb96467)), closes [#​30013](https://github.com/bitnami/charts/issues/30013) ### [`v16.0.3`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1603-2024-10-16-small) - \[bitnami/postgresql] Release 16.0.3 ([#​29942](https://github.com/bitnami/charts/issues/29942)) ([7b3f2bb](https://github.com/bitnami/charts/commit/7b3f2bb7a65a78cba10fe8dfe87fd47b55dd8ec0)), closes [#​29942](https://github.com/bitnami/charts/issues/29942) ### [`v16.0.2`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1602-2024-10-16-small) - \[bitnami/postgresql] Release 16.0.2 ([#​29938](https://github.com/bitnami/charts/issues/29938)) ([766c157](https://github.com/bitnami/charts/commit/766c1577e867aea17e1e9b21cc25f9e27b299273)), closes [#​29938](https://github.com/bitnami/charts/issues/29938) - Update documentation links to techdocs.broadcom.com ([#​29931](https://github.com/bitnami/charts/issues/29931)) ([f0d9ad7](https://github.com/bitnami/charts/commit/f0d9ad78f39f633d275fc576d32eae78ded4d0b8)), closes [#​29931](https://github.com/bitnami/charts/issues/29931) ### [`v16.0.1`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#small1601-2024-10-04-small) - \[bitnami/postgresql] Release 16.0.1 ([#​29776](https://github.com/bitnami/charts/issues/29776)) ([9d7fcdc](https://github.com/bitnami/charts/commit/9d7fcdc44c4f0939fb0006fb04d4161080cb558a)), closes [#​29776](https://github.com/bitnami/charts/issues/29776) ### [`v16.0.0`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql/CHANGELOG.md#1600-2024-10-02) - \[bitnami/postgresql] Release 16.0.0 ([#​29723](https://github.com/bitnami/charts/issues/29723)) ([aeedc0e](https://github.com/bitnami/charts/commit/aeedc0e67b1593191aa0c3cb2239864d0b3c9a58)), closes [#​29723](https://github.com/bitnami/charts/issues/29723) </details> --- ### 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:eyJjcmVhdGVkSW5WZXIiOiIzOS40MC4xIiwidXBkYXRlZEluVmVyIjoiMzkuMTU2LjEiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbImtpbmQvZGVwZW5kZW5jeSJdfQ==--> Co-authored-by: pat-s <patrick.schratz@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/736 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> |
||
|
Renovate Botandpat-s
|
70cc590eb3 |
chore(deps): update postgresql-ha docker tag to v15 (#741)
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 | `14.3.10` -> `15.1.7` | --- ### Release Notes <details> <summary>bitnami/charts (postgresql-ha)</summary> ### [`v15.1.7`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#1517-2025-02-02) - \[bitnami/postgresql-ha] Release 15.1.7 ([#​31701](https://github.com/bitnami/charts/pull/31701)) ### [`v15.1.6`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#small1516-2025-01-13-small) - \[bitnami/postgresql-ha] Release 15.1.6 ([#​31341](https://github.com/bitnami/charts/issues/31341)) ([30c2b39](https://github.com/bitnami/charts/commit/30c2b394da7c7438ac98f56767c1d45b517a396c)), closes [#​31341](https://github.com/bitnami/charts/issues/31341) ### [`v15.1.5`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#small1515-2025-01-13-small) - \[bitnami/postgresql-ha] setting ServiceAccount also when is not created by the bitnami chart ([#​31293](https://github.com/bitnami/charts/issues/31293) ([2316c35](https://github.com/bitnami/charts/commit/2316c354ab2b1cb54f57e0b5f0e108faec7d523b)), closes [#​31293](https://github.com/bitnami/charts/issues/31293) ### [`v15.1.4`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#small1514-2024-12-23-small) - \[bitnami/postgresql-ha] Release 15.1.4 ([#​31144](https://github.com/bitnami/charts/issues/31144)) ([6a0ca8f](https://github.com/bitnami/charts/commit/6a0ca8f0d148a69e005f39bb2bef839ac8fb35ad)), closes [#​31144](https://github.com/bitnami/charts/issues/31144) ### [`v15.1.3`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#small1513-2024-12-23-small) - \[bitnami/postgresql-ha] Release 15.1.3 ([#​31135](https://github.com/bitnami/charts/issues/31135)) ([b1fde05](https://github.com/bitnami/charts/commit/b1fde05a5dcb73ca619da5300686562f70d8fb1c)), closes [#​31135](https://github.com/bitnami/charts/issues/31135) ### [`v15.1.2`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#small1512-2024-12-20-small) - \[bitnami/\*] Fix typo in README ([#​31052](https://github.com/bitnami/charts/issues/31052)) ([b41a51d](https://github.com/bitnami/charts/commit/b41a51d1bd04841fc108b78d3b8357a5292771c8)), closes [#​31052](https://github.com/bitnami/charts/issues/31052) - \[bitnami/postgresql-ha] Fix typo in documentation ([#​31069](https://github.com/bitnami/charts/issues/31069)) ([b3b4ac7](https://github.com/bitnami/charts/commit/b3b4ac71e48c593a1e4da42b00445fb0ec47b1c1)), closes [#​31069](https://github.com/bitnami/charts/issues/31069) - \[bitnami/postgresql-ha] Release 15.1.2 ([#​31132](https://github.com/bitnami/charts/issues/31132)) ([a352680](https://github.com/bitnami/charts/commit/a352680c0b1a3c92b24b2888ed5fb8d532f9ba6d)), closes [#​31132](https://github.com/bitnami/charts/issues/31132) ### [`v15.1.1`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#small1511-2024-12-13-small) - \[bitnami/postgresql-ha]Add Storage Class Configuration to Templates ([#​30993](https://github.com/bitnami/charts/issues/30993)) ([485796b](https://github.com/bitnami/charts/commit/485796bfe633a508a8d679548d0fdb024a8ad92e)), closes [#​30993](https://github.com/bitnami/charts/issues/30993) ### [`v15.1.0`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#1510-2024-12-10) - \[bitnami/\*] Add Bitnami Premium to NOTES.txt ([#​30854](https://github.com/bitnami/charts/issues/30854)) ([3dfc003](https://github.com/bitnami/charts/commit/3dfc00376df6631f0ce54b8d440d477f6caa6186)), closes [#​30854](https://github.com/bitnami/charts/issues/30854) - \[bitnami/postgresql-ha] Detect non-standard images ([#​30937](https://github.com/bitnami/charts/issues/30937)) ([5149845](https://github.com/bitnami/charts/commit/51498454247984c12b9b60ba51bad0b7e72ac36c)), closes [#​30937](https://github.com/bitnami/charts/issues/30937) ### [`v15.0.4`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#small1504-2024-12-03-small) - \[bitnami/postgresql-ha] Release 15.0.4 ([#​30732](https://github.com/bitnami/charts/issues/30732)) ([dd65642](https://github.com/bitnami/charts/commit/dd6564295a9a3bf1e56ba16663ee6b6e92ff4721)), closes [#​30732](https://github.com/bitnami/charts/issues/30732) ### [`v15.0.3`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#small1503-2024-12-03-small) - \[bitnami/\*] docs: 📝 Add "Backup & Restore" section ([#​30711](https://github.com/bitnami/charts/issues/30711)) ([35ab536](https://github.com/bitnami/charts/commit/35ab5363741e7548f4076f04da6e62d10153c60c)), closes [#​30711](https://github.com/bitnami/charts/issues/30711) - \[bitnami/\*] docs: 📝 Add "Update Credentials" (batch 3) ([#​30688](https://github.com/bitnami/charts/issues/30688)) ([10a49f9](https://github.com/bitnami/charts/commit/10a49f9ff2db1d9d11a6edd1c40a9f61803241bc)), closes [#​30688](https://github.com/bitnami/charts/issues/30688) - \[bitnami/postgresql-ha] Release 15.0.3 ([#​30730](https://github.com/bitnami/charts/issues/30730)) ([1e7e0de](https://github.com/bitnami/charts/commit/1e7e0dee586aa31d3b461996c35bb4a0b3a63048)), closes [#​30730](https://github.com/bitnami/charts/issues/30730) ### [`v15.0.2`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#small1502-2024-11-28-small) - \[bitnami/\*] docs: 📝 Add "Prometheus metrics" (batch 5) ([#​30674](https://github.com/bitnami/charts/issues/30674)) ([ed2a546](https://github.com/bitnami/charts/commit/ed2a54617faf763169e6b01a89100b9db32e1000)), closes [#​30674](https://github.com/bitnami/charts/issues/30674) - \[bitnami/postgresql-ha] Release 15.0.2 ([#​30676](https://github.com/bitnami/charts/issues/30676)) ([de62c88](https://github.com/bitnami/charts/commit/de62c88da5a70863d53786a71c8a2614f3b0a3de)), closes [#​30676](https://github.com/bitnami/charts/issues/30676) ### [`v15.0.1`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#small1501-2024-11-27-small) - \[bitnami/postgresql-ha] Release 15.0.1 ([#​30644](https://github.com/bitnami/charts/issues/30644)) ([ebb2f96](https://github.com/bitnami/charts/commit/ebb2f960e7220e80e4f3fcaf98cf7bc332d81c8a)), closes [#​30644](https://github.com/bitnami/charts/issues/30644) ### [`v15.0.0`](https://github.com/bitnami/charts/blob/HEAD/bitnami/postgresql-ha/CHANGELOG.md#1500-2024-11-25) - \[bitnami/postgresql-ha] Release 15.0.0 ([#​30618](https://github.com/bitnami/charts/issues/30618)) ([2d17a50](https://github.com/bitnami/charts/commit/2d17a504663ae7b5088c1122865176828cec739a)), closes [#​30618](https://github.com/bitnami/charts/issues/30618) </details> --- ### 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:eyJjcmVhdGVkSW5WZXIiOiIzOS40MC4xIiwidXBkYXRlZEluVmVyIjoiMzkuMTU2LjEiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbImtpbmQvZGVwZW5kZW5jeSJdfQ==--> Co-authored-by: pat-s <patrick.schratz@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/741 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> |
||
|
volker.raschek
|
4f42f4bee3 |
[Close #771] fix: set GOMAXPROCS (#772)
The following patch add automatically the environment variable `GOMAXPROCS`, when a CPU limit is defined. Otherwise CPU throttling may occur. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/772 Reviewed-by: techknowlogick <techknowlogick@noreply.gitea.com> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com> Co-authored-by: Markus Pesch <markus.pesch@cryptic.systems> Co-committed-by: Markus Pesch <markus.pesch@cryptic.systems> |