### Description of the change
With https://github.com/go-gitea/gitea/pull/28390, Gitea 1.21.2 introduced warning log output within the result of `gitea admin <subcommand>` and therefore affects the current provisioning script.
That script previously assumed a clean result set and was therefore doomed to fail at _some_ point.
This introduces output sanitizing to trim such logs above the actual result table.
### Applicable issues
- fixes#589
### Additional information
The non-sanitized output were only an issue for admin account provisioning, and only when the username matched one of these words (in case of #589 it was `gitea`):
```text
.../setting/security.go:168:loadSecurityFrom() [W] Enabling Query API Auth tokens is not recommended. DISABLE_QUERY_AUTH_TOKEN will default to true in gitea 1.23 and will be removed in gitea 1.24.
```
LDAP and OAuth sources were not affected by this particular log line, but also processed non-sanitized result sets. Changing their code is a precaution.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/590
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
# Changes
A big shoutout to @luhahn for all his work in #205 which served as the base for this PR.
## Documentation
- [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long).
Most of the information below should go into it with more details and explanations behind all of the individual components.
## Chart deps
~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~
~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~
- Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2.
- Removes `memcached` instead of `redis-cluster`
- Add `postgresql-ha` as default DB dep in favor of `postgres`
## Adds smart HA chart logic
The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1.
- If `replicaCount` > 1,
- `gitea.config.session.PROVIDER` is automatically set to `redis-cluster`
- `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch`
- `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not
Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc.
## Deployment vs Statefulset
Given all the discussions about this lately (#428), I think we could use both.
In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets.
On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment.
Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption.
Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case.
This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet.
The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way?
## Chart PVC Creation
I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation.
In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial.
A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse...
- New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim`
- New `persistence.create`: whether to create a new PVC
## Testing
As this PR does a lot of things, we need proper testing.
The helm chart can be installed from the Git branch via `helm-git` as follows:
```
helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment
helm install gitea --version 0.0.0
```
It is **highly recommended** to test the chart in a dedicated namespace.
I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine.
I just did some basic operations though and we should do more niche testing before merging.
Examplary `values.yml` for testing (only needs a valid RWX storage class):
<details>
<summary>values.yaml</summary>
```yml
image:
tag: "dev"
PullPolicy: "Always"
rootless: true
replicaCount: 2
persistence:
enabled: true
accessModes:
- ReadWriteMany
storageClass: FIXME
redis-cluster:
enabled: false
global:
redis:
password: gitea
gitea:
config:
indexer:
ISSUE_INDEXER_ENABLED: true
REPO_INDEXER_ENABLED: false
```
</details>
## Preferred setup
The preferred HA setup with respect to performance and stability might currently be as follows:
- Repos: RWX (e.g. EFS or Azurefiles NFS)
- Issue indexer: Meilisearch (HA)
- Session and cache: Redis Cluster (HA)
- Attachments/Avatars: Minio (HA)
This will result in a ~ 10-pod HA setup overall.
All pods have very low resource requests.
fix#98
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
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: https://gitea.com/gitea/helm-chart/pulls/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: https://gitea.com/gitea/helm-chart/pulls/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: https://gitea.com/gitea/helm-chart/pulls/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: https://gitea.com/gitea/helm-chart/pulls/343
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
### Description of the change
Checking the existence of the config directory should be done with the directory path itself. Not its parent directory.
This simple fix addresses that by using the config directory for its existence check.
### Benefits
Prior to #337 there was no other way to install this helm chart using the `extraVolumeMounts` setting with these values:
```yaml
replicaCount: %d
extraVolumes:
- name: config-volume
configMap:
name: %s
extraVolumeMounts:
- name: config-volume
mountPath: /data/gitea/templates/custom
```
Without this fix, the Gitea pod would never initialize, and would crashloop with the same error in #296.
### Additional information
Mounting a configMap to `/data/gitea/templates/custom` causes the `/data/gitea` folder to exist even though the `/data/gitea/conf` had not been initialized yet. The initialization script saw that the `/data/gitea` dir existed and exited early without initializing `/data/gitea/conf`.
Co-authored-by: cboin1996 <christianboin@hotmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/310
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Co-authored-by: cboin1996 <cboin1996@noreply.gitea.io>
Co-committed-by: cboin1996 <cboin1996@noreply.gitea.io>
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: https://gitea.com/gitea/helm-chart/pulls/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>
## Context
PR #259 introduced support for running Gitea as a uid different than 1000 (git) or 0 (root).
## Problem
In init_directory_structure.sh, there is a "chown 1000:1000" on /tmp/gitea.
This chown only works when running as root or when the target directory is already owned by uid 1000.
As a result, the init container "init-directories" fails on startup when running Gitea with a uid different from 0 or 1000.
Initially, I worked around it by implementing an "initPreScript". But it would make user's life easier if we can make it work out-of-the-box.
## Resolution
I'm taking model on the chown a few lines above that depends on the value of image.rootless. Since the chown only works on default (root) image and is useless on rootless image, there is no need to run it on rootless image.
Co-authored-by: Nicolas MASSE <nicolas.masse@itix.fr>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/266
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
Co-committed-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
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: https://gitea.com/gitea/helm-chart/pulls/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>
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: https://gitea.com/gitea/helm-chart/pulls/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: https://gitea.com/gitea/helm-chart/pulls/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>
These changes rewrite the init script to be error aware, informative and have a bit more security awareness.
During rewrite several hidden bugs could be identified and fixed, such as:
- LDAP configuration options interpreted by the shell before passed to command
- Finding multiple ldap ids instead of one during lookup when their names are almost identical
e.g. `_my-ldap-auth` and `my-ldap-auth`
- Properly filter auth sources by their types to prevent unintended type converting attempts that fail
In addition to that the script is a bit cleaner. Some commands do not exist anymore and would cause false-positive errors during script execution.
Helps for: #149
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/178
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
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: https://gitea.com/gitea/helm-chart/pulls/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>
Allow admin user and password to be configured via existing secrets
Allow LDAP bindDn and bindPassword to be configured via existing secrets
Update Readme
Fixes: #169
Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/170
Reviewed-by: techknowlogick <techknowlogick@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>
Due to #160 it was no longer possible to create repositories in root-based containers. This was caused by the missing `/tmp/gitea` directory in that image. It was dynamically created by Gitea internal functionality with less privileges than necessary.
Explicitly creating the directory and set proper permissions fix this.
Fixes: #171
Co-authored-by: JustusBunsi <sk.bunsenbrenner@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/172
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: 6543 <6543@obermui.de>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
The chown in the init container will fail in the rootles image.
Checking if the image is rootless or not will prevent this error noise.
Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/165
Reviewed-by: Andrew Thornton <art27@cantab.net>
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: luhahn <luhahn@noreply.gitea.io>
Co-committed-by: luhahn <luhahn@noreply.gitea.io>
This PR includes the changes from:
- https://gitea.com/gitea/helm-chart/pulls/129
- https://gitea.com/gitea/helm-chart/pulls/140
In addition it adds the possibility to include secrets via environment variables as mentioned in #60
Co-authored-by: Hans Kristian Flaatten <hans.flaatten@evry.com>
Co-authored-by: flavio.prado <flavio.prado@noreply.gitea.io>
Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/148
Reviewed-by: techknowlogick <techknowlogick@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>
There are currently 2 issues that prevent using this chart to deploy gitea with a SQLite3 database.
1) The value from *gitea.config.database.HOST* is used to set *db.servicename* when all the databases under *gitea.database.buildIn* are not enabled. This causes a type error during the template processing:
`Error: UPGRADE FAILED: template: gitea/templates/gitea/init.yaml:24:20: executing "gitea/templates/gitea/init.yaml" at <include "db.servicename" .>: error calling include: template: gitea/templates/_helpers.tpl:64:31: executing "db.servicename" at <.Values.gitea.config.database.HOST>: wrong type for value; expected string; got interface {}`
2) In *init_gitea.sh*, we use the value *db.servicename* and *db.port* to ping the database. If this database responds to ping, we proceed with the init. The problem here is that *db.port* is not set when all the databases under *gitea.database.buildIn* are disabled. In turn, this raises an error from busybox's *nc*, because no parameter is passed for *PORT*. This causes the init container to go in *CrashLoopBackOff* forever.
The simple fix that is proposed in this PR is to check wether or not *.Values.gitea.config.database.DB_TYPE* is set to determine the value *db.servicename*. If *DB_TYPE* is *'sqlite3'*, leave *db.servicename* empty and use that to bypass the database ping.
Co-authored-by: Baptiste Covolato <b.covolato@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/124
Reviewed-by: Andrew Thornton <art27@cantab.net>
Reviewed-by: lafriks <lafriks@noreply.gitea.io>
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Co-authored-by: Nakrez <nakrez@noreply.gitea.io>
Co-committed-by: Nakrez <nakrez@noreply.gitea.io>
I opened up the OAuth2 authentication option. I needed this feature, and it is available in the gitea cli. So I opened it up for configuration through this pull request.
Hope it can help others.
Co-authored-by: Marc Went <marc.went+git@redkubes.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/123
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: lafriks <lafriks@noreply.gitea.io>
Co-authored-by: Dunky13 <dunky13@noreply.gitea.io>
Co-committed-by: Dunky13 <dunky13@noreply.gitea.io>
This PR adds a few new chart features which adds to the flexibility of the chart.
- allow extra volumes to be mounted (such as secrets): 2f862c5a48
- pass environment variables also to the init-container: 7044049478
- allow a preparation script to be "injected" into the init-container: 6125a69345
As a concrete example of how this can be used, I use is to configure Gitea to use client certificate authentication against an external Postgres database. That could be accomplished by having a `gitea-postgres-ssl` secret:
```
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: gitea-postgres-ssl
data:
postgresql.crt: <base64...>
postgresql.key: <base64...>
root.crt: <base64...>
```
and then mounting this as a volume in Gitea using:
```
extraVolumes:
- name: postgres-ssl-vol
secret:
secretName: gitea-postgres-ssl
extraVolumeMounts:
- name: postgres-ssl-vol
readOnly: true
mountPath: "/pg-ssl"
```
To get the right permissions on the credentials, we'd use the `initPreScript`:
```
initPreScript: |
# copy postgres client and CA cert from mount and
# give proper permissions
mkdir -p /data/git/.postgresql
cp /pg-ssl/* /data/git/.postgresql/
chown -R git:git /data/git/.postgresql/
chmod 400 /data/git/.postgresql/postgresql.key
```
and to make sure that Gitea uses the certificate we need to pass the proper postgres environment variables (both to the init container and the "main" container):
```
statefulset:
env:
- name: "PGSSLCERT"
value: "/data/git/.postgresql/postgresql.crt"
- name: "PGSSLKEY"
value: "/data/git/.postgresql/postgresql.key"
- name: "PGSSLROOTCERT"
value: "/data/git/.postgresql/root.crt"
```
Co-authored-by: Peter Gardfjäll <peter.gardfjall.work@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/47
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: 6543 <6543@obermui.de>
Co-authored-by: petergardfjall <petergardfjall@noreply.gitea.io>
Co-committed-by: petergardfjall <petergardfjall@noreply.gitea.io>
Improve ldap settings with helper function
Allow clusterIP for http service to be set, default to None
Use imagePullSecrets in statefulset now
Update default values
Update README
Bump Chart version
Co-authored-by: luhahn <lucas.hahn@novum-rgi.de>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/87
Reviewed-by: lafriks <lafriks@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>
Fix admin user creation for gitea 1.13.0
Add load balancer hint for ssh in README
Merge branch 'master' into fix-admin-user-creation
Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/80
Reviewed-by: Andrew Thornton <art27@cantab.net>
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-Authored-By: luhahn <luhahn@noreply.gitea.io>
Co-Committed-By: luhahn <luhahn@noreply.gitea.io>
Bump Chart version
Move all password related data to secrets
Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/28
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
