### Description of the change Adds support for setting priorityClassName on the Gitea pod. ### Benefits Users can take advantage of https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/ with Gitea. ### Applicable issues - fixes #429 ### 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) Reviewed-on: gitea/helm-chart#430 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Co-authored-by: Casey Buto <cbuto@d2iq.com> Co-committed-by: Casey Buto <cbuto@d2iq.com>

Supersedes stalled #362 I opted for defining `requests` while leaving `limits` open. This might help for scheduling without restricting performance during init. Reviewed-on: gitea/helm-chart#423 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>

And allow overriding the `image` section so users could possible also use other image tags. fix #285 Reviewed-on: gitea/helm-chart#422 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>

### Description of the change Removes checks for mariadb and mysql from _helpers.tpl ### Benefits Fixes the helm-chart version 8.0.0 if using a external database ### Applicable issues - fixes #420 - fixes #419 Reviewed-on: gitea/helm-chart#421 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: John Olheiser <john+gitea@jolheiser.com> Reviewed-by: delvh <dev.lh@web.de> Reviewed-by: yardenshoham <yardenshoham@noreply.gitea.io> Co-authored-by: Maximilian Marschall <maximilian.marschall@3xm.at> Co-committed-by: Maximilian Marschall <maximilian.marschall@3xm.at>

As discussed in Discord. Supersedes #412 and #407. **⚠️ BREAKING** Users depending on the built-in MySQL or MariaDB chart have to switch to an self-managed database, or Postgres Reviewed-on: gitea/helm-chart#417 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: John Olheiser <john+gitea@jolheiser.com> Reviewed-by: yardenshoham <yardenshoham@noreply.gitea.io> Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>

See discussion in #387 Upgrade notes to Chart v11.x and Postgres 14.x: https://docs.bitnami.com/kubernetes/infrastructure/postgresql/administration/upgrade/ The current version in Gitea is using `11.11.0-debian-10-r62` from 2021-04. Bumping the chart to the latest (v12.x) would use the image `15.2.0-debian-11-r14` which would be a jump from postgres 11 to postgres 15. There are no specific notes for the v12.x chart release, hence we might be able to just go to 12.x directly. There have been some param renamings which I've reflected in the README. **⚠️ BREAKING** Users have to migrate their Postgres DB by e.g. restoring a previously created database dump into a clean installation. Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: gitea/helm-chart#391 Reviewed-by: techknowlogick <techknowlogick@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>

Re gitea/helm-chart#224 (comment) Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: gitea/helm-chart#358 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: strk <strk@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: pi3ch <pi3ch@noreply.gitea.io> Co-committed-by: pi3ch <pi3ch@noreply.gitea.io>

### 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: gitea/helm-chart#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 Make the test-connection Pod optional and override the wget container's image. ### Benefits Allows users to enable/disabled the test-connection Pod and override the wget container's image. ### 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` Co-authored-by: Umer Anwar <umer.anwar@nuance.com> Co-authored-by: ooms97 <anwarumer97@gmail.com> Reviewed-on: gitea/helm-chart#360 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: ooms97 <ooms97@noreply.gitea.io> Co-committed-by: ooms97 <ooms97@noreply.gitea.io>

### Description of the change It is required to add custom mapping between hostnames and IP addresses for the gitea pods to be able to access external services like oauth providers or webhook servers. It is common to take global variables for the entires and set them using hostAliases in the pod template. ### Benefits Give us more flexibility when using gitea in various network environments. ### Applicable issues - fixes #400 ### 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: Taekyun Kim <tkq.kim@samsung.com> Co-authored-by: pat-s <pat-s@noreply.gitea.io> Reviewed-on: gitea/helm-chart#401 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: podain77 <podain77@noreply.gitea.io> Co-committed-by: podain77 <podain77@noreply.gitea.io>

This reverts d5ce1a47ea and therefore adds the GPG feature back into main. As it is a breaking change, this PR now also contains the required upgrade notes. Closes #107 again. Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: gitea/helm-chart#374 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: John Olheiser <john+gitea@jolheiser.com>

Feature #343 happens to be a breaking change when enabling `.Values.signing` but not specifying any of the new private key properties. Tag `v6.0.2` is therefore not following semantic versioning. This temporarily reverts commit b8f0310c43 and a fix-up commit 57a1cd27d9 to retag 6.0.2 as 6.0.3. Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: gitea/helm-chart#373 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io>

### Description of the change The init container for gpg key import doesn´t work. There is a not a tty error. ### Benefits This will run gpg in batch mode. Eliminating the tty error. ### Possible drawbacks None that I can think off. ### Applicable issues - fixes #370 ### 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` Co-authored-by: Jeroen Verhoeven <jeroen@joentje.org> Reviewed-on: gitea/helm-chart#371 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: dajoen74 <dajoen74@noreply.gitea.io> Co-committed-by: dajoen74 <dajoen74@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: gitea/helm-chart#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: gitea/helm-chart#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>

Reviewed-on: gitea/helm-chart#337 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>

Reviewed-on: gitea/helm-chart#336 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>

Reviewed-on: gitea/helm-chart#335 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>

Reviewed-on: gitea/helm-chart#94 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: huww98 <huww98@outlook.com> Co-committed-by: huww98 <huww98@outlook.com>

Description of the change Add support for a new value: dnsConfig, to be passed to the statefulset pod template configuration. Default is {}, and does not change anything from current default pod configuration. Benefits Ability to fix some issues encountered with Alpine-based docker images, which may break DNS resolving on some clusters. In particular, this allows to lower the ndots value, which fixes DNS resolving of FQDNs. dnsConfig: options: - name: ndots value: "1" Also, with this setting, one can set other parameters to finely tune DNS configuration for Gitea pods, if needed: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config Possible drawbacks None. Additional information Some relevant links about the issue this setting allows to fix: https://stackoverflow.com/questions/65181012/does-alpine-have-known-dns-issue-within-kubernetes https://gitlab.alpinelinux.org/alpine/aports/-/issues/9017 Checklist Parameters are documented in the values.yaml and added to the README.md using readme-generator-for-helm Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/329 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Co-authored-by: dek <dek@noreply.gitea.io> Co-committed-by: dek <dek@noreply.gitea.io>

Reviewed-on: gitea/helm-chart#323 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: cnfatal <cnfatal@noreply.gitea.io> Co-committed-by: cnfatal <cnfatal@noreply.gitea.io>

Reviewed-on: gitea/helm-chart#322 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: cnfatal <cnfatal@noreply.gitea.io> Co-committed-by: cnfatal <cnfatal@noreply.gitea.io>

To enable access to e.g. the SSH port by IPv6, the selection of ipFamilyPolicy and ipFamilies service attributes is necessary. Enable the possibility to configure these by helm values. Co-authored-by: Sven Fischer <sven@leiderfischer.de> Reviewed-on: gitea/helm-chart#313 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Co-authored-by: svenihoney <svenihoney@noreply.gitea.io> Co-committed-by: svenihoney <svenihoney@noreply.gitea.io>

The default behaviour for container image pulls depend on different values such as image tag usage and its value. See https://kubernetes.io/docs/concepts/containers/images/#imagepullpolicy-defaulting It leads to an unintended behaviour for this Helm Chart. Kubernetes will always pull the image for init containers when using the `latest` Gitea image tag, even if `Values.image.pullPolicy` defines a different value for the runtime container. Reviewed-on: gitea/helm-chart#317 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Gusted <williamzijl7@hotmail.com> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>

Fixes #314 Right now, the gitea StatefulSet does not allow any annotations to be configured via the helmchart - see https://gitea.com/gitea/helm-chart/src/tag/v5.0.4/templates/gitea/statefulset.yaml#L4-L6 My use case: I am trying to use Reloader (https://github.com/stakater/Reloader) so that I can configure my values.yaml such that i can set some annotations on the StatefulSet and thus Reloader can rollout a restart of gitea StatefulSet whenever a watched secret or configmap is updated. Co-authored-by: Tarun Gupta Akirala <tarugupta.92@gmail.com> Reviewed-on: gitea/helm-chart#315 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: takirala <takirala@noreply.gitea.io> Co-committed-by: takirala <takirala@noreply.gitea.io>

This PR improves the handling and injection into _app.ini_ of user defined environment variables via env-to-ini script. Fixes #297 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: gitea/helm-chart#298 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: 6543 <6543@obermui.de>

This will remove the db connection check, which has caused some trouble in the past. It will now simply run _gitea migrate_ and output a message, if the database is not available. Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-on: gitea/helm-chart#299 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>

- Drop super legacy `image.version` value (see #92 description) - Always use `appVersion` from Chart.yaml as image tag if non specified --- Don't know whether this is a breaking change regarding image.version drop. Reviewed-on: gitea/helm-chart#250 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>

This fixes my feature request (#275) to support hostPort to expose the ssh port. Co-authored-by: alex <alex@zengers.de> Reviewed-on: gitea/helm-chart#276 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: a-zen <a-zen@noreply.gitea.io> Co-committed-by: a-zen <a-zen@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: gitea/helm-chart#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: gitea/helm-chart#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>

⚠️ Breaking Moved the values to enable the dependencies into the dependencies itself, this way we don't need a seperate field in the values and it is more obvious how to enable for example postgresql. Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: gitea/helm-chart#268 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net>

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: gitea/helm-chart#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>

As this key must not exist anymore, we don't have to check it. Reviewed-on: gitea/helm-chart#267 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>

This change request includes two different things to improve OAuth source handling: - Allow multiple OAuth source configuration (Fixes: #191) - Support reading sensitive OAuth configuration data from Kubernetes secrets (Closes: #242) ⚠️ BREAKING ⚠️ --- Users need to migrate their `gitea.oauth` configuration. Reviewed-on: gitea/helm-chart#244 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>

Hello, PR adds a `persistence.subPath` option to provide user more flexibility on mounting the `data` PV. https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath The setting is similar to e.g. `primary.persistence.subPath` in MariaDB helm chart: https://github.com/bitnami/charts/tree/master/bitnami/mariadb Co-authored-by: Aleksey Sergey <sergey.aleksey90@gmail.com> Reviewed-on: gitea/helm-chart#263 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Co-authored-by: aleksey.sergey <aleksey.sergey@noreply.gitea.io> Co-committed-by: aleksey.sergey <aleksey.sergey@noreply.gitea.io>

fixes #251 The rendering is a bit more programatic but the result is the same if you don't have an override. This makes the code a little easier at the end of the template, and slightly less easier to read at the beginning, which I think is a valid tradeoff. Co-authored-by: Martyn Ranyard <m@rtyn.berlin> Reviewed-on: gitea/helm-chart#252 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Co-authored-by: iMartyn <imartyn@noreply.gitea.io> Co-committed-by: iMartyn <imartyn@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: gitea/helm-chart#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>

As a replacement, the default probes are now fully configurable and used as-is during Chart deployment. Fixes: #189 ⚠️ BREAKING ⚠️ --- Users have to remove the `custom` prefix from their probes, if customized. Reviewed-on: gitea/helm-chart#248 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>

App ini is now generated by environment-to-ini This should prevent some of the problems we had earlier with persisting the app.ini Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: gitea/helm-chart#239 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>

Add multiple add sources. Instead of a single entry for ldap configuration we now would have a dictionary for ldap config. This would be a breaking change for those working with the ldap config. fixes: #190 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: gitea/helm-chart#222 Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>

Hi, I just add some minor changes to support specifying ingressClassName to support the newer specification in `networking.k8s.io/v1`. The annotation `kubernetes.io/ingress.class: nginx` only works with older API `networking.k8s.io/v1beta1`. This is part of our move to support kubernetes 1.22. Co-authored-by: Leong Wai Kit <waikit.leong@bertelsmann.de> Reviewed-on: gitea/helm-chart#217 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: wkit23 <wkit23@noreply.gitea.io> Co-committed-by: wkit23 <wkit23@noreply.gitea.io>

Only create conf directory if not yet exists fixes #210 Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-on: gitea/helm-chart#211 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: Michael Kriese <michael.kriese@visualon.de> Co-committed-by: Michael Kriese <michael.kriese@visualon.de>

Fix for #203 Co-authored-by: techknowlogick <techknowlogick@gitea.io> Reviewed-on: gitea/helm-chart#204 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: skriesch <skriesch@noreply.gitea.io> Co-committed-by: skriesch <skriesch@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: gitea/helm-chart#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: gitea/helm-chart#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>

In case a user did not specify DOMAIN in .Values.gitea.config.server, the chart generated incorrect value for that app.ini setting so that Gitea crashed on startup. Same for ROOT_URL. Co-authored-by: techknowlogick <techknowlogick@gitea.io> Reviewed-on: gitea/helm-chart#185 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: gitea/helm-chart#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>

Adds support for a custom Ingress path. This allows us to run Gitea as a path in an existing domain. Co-authored-by: Matt Kaar <mkaar@cert.org> Reviewed-on: gitea/helm-chart#151 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: mattkaar <mattkaar@noreply.gitea.io> Co-committed-by: mattkaar <mattkaar@noreply.gitea.io>

This fixes several flaws introduced by commits for #169 (see c49dc047a4). - Respect kebab-case ldap bind inline definition - Prevent camelCase ldap bind inline definition from being overridden by empty string - Create admin account when `existingSecret` is used Reviewed-on: gitea/helm-chart#183 Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>