Currently there are two different styles for defining both ldap and oauth configuration in _values.yaml_ file: `camelCase` and `kebab-case`.
Supporting both styles created multiple regressions in the past.
⚠️ BREAKING ⚠️
---------------
These changes completely remove any support for `kebab-case` notation in _values.yaml_ in favor of `camelCase`. Configuration keys must use `camelCase`.
Only exception are Kubernetes resource keys for annotations or labels.
Fixes: #188
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/196
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
These changes rewrite the init script to be error aware, informative and have a bit more security awareness.
During rewrite several hidden bugs could be identified and fixed, such as:
- LDAP configuration options interpreted by the shell before passed to command
- Finding multiple ldap ids instead of one during lookup when their names are almost identical
e.g. `_my-ldap-auth` and `my-ldap-auth`
- Properly filter auth sources by their types to prevent unintended type converting attempts that fail
In addition to that the script is a bit cleaner. Some commands do not exist anymore and would cause false-positive errors during script execution.
Helps for: #149
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/178
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
The `HOME` path is not persistent when using the rootless image, so the
`.gnupg` folder isn't either. Since the chart always used `/data/...` as
mount point for storage of all kinds, it is a minimal impact to just
relocate the dynamic `$HOME/.gnupg` folder location to the persistent
`/data/git/.gnupg`. This is where the signing keys are stored when
running root based environments. Doing so will
- allow migrations between both image variants
- persist signing keys for rootless environments
Fixes: #155
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/186
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
I've noticed that the commented `securityContext` is not really useable with the rootless image due to different directory structure compared to the default image.
Important for the `readOnlyRootFilesystem` is to declare the `TMPDIR` environment variable, so that the tmp directory (which is readonly in this case) won't be used. Instead, another writeable directory can be used.
Another thing is the explicit hint that all these security options cannot be used with the default (root-based) image, because of its design.
~~Although this PR would fix the referenced issue, I am not totally happy with the current implementation. It would be more straight forward to use the same mount points for both image variants. Unfortunately, this is not possible right now due to hard coded paths in the default (root) image startup scripts.~~
~~Anyone have suggestions on how this could be more simple?~~
-------
**Sum-up:**
As mentioned in Discord, this PR tried to make too many changes. The necessary changes made in 1f331a7e6577fc798196a84a957330aca0d663cd will fix an error that occurs due to restricted access to the `/tmp` directory in a rootless image with all the `securityContext` options enabled.
I also updated the default image to 1.14.2.
Fixes: #158
Co-authored-by: JustusBunsi <sk.bunsenbrenner@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/160
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: 6543 <6543@obermui.de>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
This change adds a new value *statefulset.labels* to allow the user to add custom labels to the StatefulSet.
An example of where this could be useful is if gitea's pvc is stored on OpenEBS. With this new option, the user can add the extra *openebs.io/sts-target-affinity* label to specify that the volume target pod should run on the same node as gitea's StatefulSet.
Co-authored-by: Baptiste Covolato <b.covolato@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/130
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: lafriks <lafriks@noreply.gitea.io>
Co-authored-by: Nakrez <nakrez@noreply.gitea.io>
Co-committed-by: Nakrez <nakrez@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>
This pull request adds the `app` and `version` labels that are used by Istio.
> Pods with app and version labels: We recommend adding an explicit app label and version label to the specification of the pods deployed using a Kubernetes Deployment. The app and version labels add contextual information to the metrics and telemetry that Istio collects.
>
> * The app label: Each deployment should have a distinct app label with a meaningful value. The app label is used to add contextual information in distributed tracing.
>
> * The version label: This label indicates the version of the application corresponding to the particular deployment.
From https://istio.io/latest/docs/ops/deployment/requirements/#pod-requirements
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/121
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: lafriks <lafriks@noreply.gitea.io>
Co-authored-by: Starefossen <starefossen@noreply.gitea.io>
Co-committed-by: Starefossen <starefossen@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>
Adding same changes to cache
Deleted useDefaultHost value
no longer needed
Eliminated need for useDefaultHost value
Using whether gitea.config.database.HOST exists instead in the values file. If true, don't overwrite. If false, use "mysql/postgresql.dns"
Updated db host logic
Config map uses "postgresql/mysql.dns" when useDefaultHost is true, and the value from gitea.config.database.HOST when useDefaultHost is false.
Added useDefaultHost to built in database values.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/23
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
# additional volumes to add to the Gitea statefulset.
extraVolumes:
# - name: postgres-ssl-vol
# secret:
# secretName: gitea-postgres-ssl
# additional volumes to mount, both to the init container and to the main
# container. As an example, can be used to mount a client cert when connecting
# to an external Postgres server.
extraVolumeMounts:
# - name: postgres-ssl-vol
# readOnly: true
# mountPath: "/pg-ssl"
# bash shell script copied verbatim to the start of the init-container.
initPreScript:""
#
# initPreScript: |
# 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
# Configure commit/action signing prerequisites
signing:
enabled:false
gpgHome:/data/git/.gnupg
gitea:
admin:
#existingSecret: gitea-admin-secret
username:gitea_admin
password:r8sA8CPHD9!bt6d
email:"gitea@local.domain"
metrics:
enabled:false
serviceMonitor:
enabled:false
# additionalLabels:
# prometheus-release: prom1
ldap:
enabled:false
name:""
securityProtocol:""
host:""
port:""
userSearchBase:""
userFilter:""
adminFilter:""
emailAttribute:""
bindDn:""
bindPassword:""
usernameAttribute:""
#existingSecret: gitea-ldap-secret
#name:
#securityProtocol:
#host:
#port:
#userSearchBase:
#userFilter:
#adminFilter:
#emailAttribute:
#bindDn:
#bindPassword:
#usernameAttribute:
#sshPublicKeyAttribute:
oauth:
enabled:false
#name:
#provider:
#key:
#secret:
#autoDiscoverUrl:
#useCustomUrls:
#customAuthUrl:
#customTokenUrl:
#customProfileUrl:
#customEmailUrl:
config:{}
# APP_NAME: "Gitea: Git with a cup of tea"
# RUN_MODE: dev
#
# RUN_MODE: dev
#
# server:
# SSH_PORT: 22
#
# security:
# PASSWORD_COMPLEXITY: spec
podAnnotations:{}
database:
builtIn:
postgresql:
enabled:true
mysql:
enabled:false
mariadb:
enabled:false
cache:
builtIn:
enabled:true
livenessProbe:
enabled:true
initialDelaySeconds:200
timeoutSeconds:1
periodSeconds:10
successThreshold:1
failureThreshold:10
readinessProbe:
enabled:true
initialDelaySeconds:5
timeoutSeconds:1
periodSeconds:10
successThreshold:1
failureThreshold:3
startupProbe:
enabled:false
initialDelaySeconds:60
timeoutSeconds:1
periodSeconds:10
successThreshold:1
failureThreshold:10
# customLivenessProbe:
# httpGet:
# path: /user/login
# port: http
# initialDelaySeconds: 60
# periodSeconds: 10
# successThreshold: 1
# failureThreshold: 10
# customReadinessProbe:
# httpGet:
# path: /user/login
# port: http
# initialDelaySeconds: 5
# periodSeconds: 10
# successThreshold: 1
# failureThreshold: 3
# customStartupProbe:
# httpGet:
# path: /user/login
# port: http
# initialDelaySeconds: 60
# periodSeconds: 10
# successThreshold: 1
# failureThreshold: 10
memcached:
service:
port:11211
@ -131,3 +279,15 @@ mysql:
port:3306
persistence:
size:10Gi
mariadb:
auth:
database:gitea
username:gitea
password:gitea
rootPassword:gitea
primary:
service:
port:3306
persistence:
size:10Gi
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
