DevFW-CICD/forgejo-helm
16
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat: add gitea chart v8.3.0 changes

Browse source
This commit is contained in:
Michael Kriese 2023-05-10 10:19:12 +02:00
commit 81bdf8fe5c
No known key found for this signature in database
GPG key ID: B83F553A0724D44E
4 changed files with 94 additions and 103 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
Chart.yaml
View file

@ -30,6 +30,7 @@ dependencies:
repository: oci://registry-1.docker.io/bitnamicharts
version: 6.4.2
condition: memcached.enabled
# Chart release date: 2023-04
- name: postgresql
repository: oci://registry-1.docker.io/bitnamicharts
version: 12.4.3

184
README.md
View file

@ -8,30 +8,28 @@ solution written in Go. It is published under the MIT license.
## Introduction
This helm chart is based on official [Gitea helm chart](https://gitea.com/gitea/helm-chart).
Additionally, this chart provides LDAP and admin user configuration with values,
as well as being deployed as a statefulset to retain stored repositories.
Additionally, this chart provides LDAP and admin user configuration with values, as well as being deployed as a statefulset to retain stored repositories.
## Update and versioning policy
The Gitea helm chart versioning does not follow Gitea's versioning.
The Forgejo helm chart versioning does not follow Forgejo's versioning.
The latest chart version can be looked up in [https://dl.gitea.com/charts](https://dl.gitea.com/charts) or in the [repository releases](https://gitea.com/gitea/helm-chart/releases).
The chart aims to follow Gitea's releases closely.
There might be times when the chart is behind the latest Gitea release.
The chart aims to follow Forgejo's releases closely.
There might be times when the chart is behind the latest Forgejo release.
This might be caused by different reasons, most often due to time constraints of the maintainers (remember, all work here is done voluntarily in the spare time of people).
If you're eager to use the latest Gitea version earlier than this chart catches up, then change the tag in `values.yaml` to the latest Gitea version.
Note that besides the exact Gitea version one can also use the `:1` tag to automatically follow the latest Gitea version.
If you're eager to use the latest Forgejo version earlier than this chart catches up, then change the tag in `values.yaml` to the latest Forgejo version.
Note that besides the exact Forgejo version one can also use the `:1` tag to automatically follow the latest Forgejo version.
This should be combined with `image.pullPolicy: "Always"`.
Important: Using the `:1` will also automatically jump to new minor release (e.g. from 1.13 to 1.14) which may eventually cause incompatibilities if major/breaking changes happened between these versions.
This is due to Gitea not strictly following [semantic versioning](https://semver.org/#summary) as breaking changes do not increase the major version.
This is due to Forgejo not strictly following [semantic versioning](https://semver.org/#summary) as breaking changes do not increase the major version.
I.e., "minor" version bumps are considered "major".
Yet most often no issues will be encountered and the chart maintainers aim to communicate early/upfront if this would be the case.
## Dependencies
Forgejo can be run with an external database and cache. This chart provides those
dependencies, which can be enabled, or disabled via
configuration.
Forgejo can be run with an external database and cache.
This chart provides those dependencies, which can be enabled, or disabled via configuration.
Dependencies:
@ -50,8 +48,7 @@ In case you want to supply values, you can reference a `values.yaml` file:
helm install forgejo -f values.yaml oci://codeberg.org/forgejo-contrib/forgejo
```
When upgrading, please refer to the [Upgrading](#upgrading) section at the bottom
of this document for major and breaking changes.
When upgrading, please refer to the [Upgrading](#upgrading) section at the bottom of this document for major and breaking changes.
## Prerequisites
@ -63,8 +60,8 @@ of this document for major and breaking changes.
### Forgejo Configuration
Forgejo offers lots of configuration options. This is fully described in the
[Gitea Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/).
Forgejo offers lots of configuration options.
This is fully described in the [Gitea Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/).
```yaml
gitea:
@ -78,18 +75,17 @@ gitea:
### Default Configuration
This chart will set a few defaults in the Forgejo configuration based on the
service and ingress settings. All defaults can be overwritten in `gitea.config`.
This chart will set a few defaults in the Forgejo configuration based on the service and ingress settings.
All defaults can be overwritten in `gitea.config`.
INSTALL_LOCK is always set to true, since we want to configure Forgejo with this
helm chart and everything is taken care of.
INSTALL_LOCK is always set to true, since we want to configure Forgejo with this helm chart and everything is taken care of.
_All default settings are made directly in the generated app.ini, not in the Values._
#### Database defaults
If a builtIn database is enabled the database configuration is set
automatically. For example, PostgreSQL builtIn will appear in the app.ini as:
If a builtIn database is enabled the database configuration is set automatically.
For example, PostgreSQL builtIn will appear in the app.ini as:
```ini
[database]
@ -102,8 +98,8 @@ USER = gitea
#### Memcached defaults
Memcached is handled the exact same way as database builtIn. Once Memcached
builtIn is enabled, this chart will generate the following part in the `app.ini`:
Memcached is handled the exact same way as database builtIn.
Once Memcached builtIn is enabled, this chart will generate the following part in the `app.ini`:
```ini
[cache]
@ -114,9 +110,9 @@ HOST = RELEASE-NAME-memcached.default.svc.cluster.local:11211
#### Server defaults
The server defaults are a bit more complex. If ingress is `enabled`, the
`ROOT_URL`, `DOMAIN` and `SSH_DOMAIN` will be set accordingly. `HTTP_PORT`
always defaults to `3000` as well as `SSH_PORT` to `22`.
The server defaults are a bit more complex.
If ingress is `enabled`, the `ROOT_URL`, `DOMAIN` and `SSH_DOMAIN` will be set accordingly.
`HTTP_PORT` always defaults to `3000` as well as `SSH_PORT` to `22`.
```ini
[server]
@ -145,14 +141,11 @@ ENABLED = false
> **The [generic](https://docs.gitea.io/en-us/config-cheat-sheet/#overall-default)
> section cannot be defined that way.**
Some settings inside _app.ini_ (like passwords or whole authentication configurations)
must be considered sensitive and therefore should not be passed via plain text
inside the _values.yaml_ file. In times of _GitOps_ the values.yaml could be stored
in a Git repository where sensitive data should never be accessible.
Some settings inside _app.ini_ (like passwords or whole authentication configurations) must be considered sensitive and therefore should not be passed via plain text inside the _values.yaml_ file.
In times of _GitOps_ the values.yaml could be stored in a Git repository where sensitive data should never be accessible.
The Helm Chart supports this approach and let the user define custom sources like
Kubernetes Secrets to be loaded as environment variables during _app.ini_ creation
or update.
Kubernetes Secrets to be loaded as environment variables during _app.ini_ creation or update.
```yaml
gitea:
@ -165,8 +158,7 @@ gitea:
This would mount the two additional volumes (`oauth` and `some-additionals`)
from different sources to the init containerwhere the _app.ini_ gets updated.
All files mounted that way will be read and converted to environment variables
and then added to the _app.ini_ using [environment-to-ini](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini).
All files mounted that way will be read and converted to environment variables and then added to the _app.ini_ using [environment-to-ini](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini).
The key of such additional source represents the section inside the _app.ini_.
The value for each key can be multiline ini-like definitions.
@ -203,19 +195,15 @@ stringData:
#### User defined environment variables in app.ini
Users are able to define their own environment variables,
which are loaded into the containers. We also support to
directly interact with the generated _app.ini_.
Users are able to define their own environment variables, which are loaded into the containers.
We also support to directly interact with the generated _app.ini_.
To inject self defined variables into the _app.ini_ a
certain format needs to be honored. This is
described in detail on the [env-to-ini](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini)
page.
To inject self defined variables into the _app.ini_ a certain format needs to be honored.
This is described in detail on the [env-to-ini](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini) page.
Note that the Prefix on this helm chart is `ENV_TO_INI`.
For example a database setting needs to have the following
format:
For example a database setting needs to have the following format:
```yaml
gitea:
@ -232,13 +220,13 @@ gitea:
Priority (highest to lowest) for defining app.ini variables:
1. Environment variables prefixed with `ENV_TO_INI`
2. Additional config sources
3. Values defined in `gitea.config`
1. Additional config sources
1. Values defined in `gitea.config`
### External Database
Any external Database listed in [https://docs.gitea.io/en-us/database-prep/](https://docs.gitea.io/en-us/database-prep/) can be used instead of the built-in PostgreSQL.
In fact, it is **highly recommended** to use an external database to ensure a stable Gitea installation longterm.
In fact, it is **highly recommended** to use an external database to ensure a stable Forgejo installation longterm.
If an external database is used, no matter which type, make sure to set `postgresql.enabled` to `false` to disable the use of the built-in PostgreSQL.
@ -259,7 +247,8 @@ postgresql:
### Ports and external url
By default port `3000` is used for web traffic and `22` for ssh. Those can be changed:
By default port `3000` is used for web traffic and `22` for ssh.
Those can be changed:
```yaml
service:
@ -269,15 +258,14 @@ service:
port: 22
```
This helm chart automatically configures the clone urls to use the correct
ports. You can change these ports by hand using the `gitea.config` dict. However
you should know what you're doing.
This helm chart automatically configures the clone urls to use the correct ports.
You can change these ports by hand using the `gitea.config` dict.
However you should know what you're doing.
### ClusterIP
By default the clusterIP will be set to None, which is the default for headless
services. However if you want to omit the clusterIP field in the service, use
the following values:
By default the `clusterIP` will be set to `None`, which is the default for headless services.
However if you want to omit the clusterIP field in the service, use the following values:
```yaml
service:
@ -293,9 +281,8 @@ service:
### SSH and Ingress
If you're using ingress and want to use SSH, keep in mind, that ingress is not
able to forward SSH Ports. You will need a LoadBalancer like `metallb` and a
setting in your ssh service annotations.
If you're using ingress and want to use SSH, keep in mind, that ingress is not able to forward SSH Ports.
You will need a LoadBalancer like `metallb` and a setting in your ssh service annotations.
```yaml
service:
@ -306,8 +293,8 @@ service:
### SSH on crio based kubernetes cluster
If you use crio as container runtime it is not possible to read from a remote
repository. You should get an error message like this:
If you use `crio` as container runtime it is not possible to read from a remote repository.
You should get an error message like this:
```bash
$ git clone git@k8s-demo.internal:admin/test.git
@ -324,15 +311,15 @@ More about this issue [here](https://gitea.com/gitea/helm-chart/issues/161).
### Cache
This helm chart can use a built in cache. The default is Memcached from bitnami.
This helm chart can use a built in cache.
The default is Memcached from bitnami.
```yaml
memcached:
enabled: true
```
If the built in cache should not be used simply configure the cache in
`gitea.config`.
If the built in cache should not be used simply configure the cache in `gitea.config`.
```yaml
gitea:
@ -346,15 +333,14 @@ gitea:
### Persistence
Forgejo will be deployed as a statefulset. By simply enabling the persistence and
setting the storage class according to your cluster everything else will be
taken care of. The following example will create a PVC as a part of the
statefulset. This PVC will not be deleted even if you uninstall the chart.
Forgejo will be deployed as a statefulset.
By simply enabling the persistence and setting the storage class according to your cluster everything else will be taken care of.
The following example will create a PVC as a part of the statefulset.
This PVC will not be deleted even if you uninstall the chart.
Please note, that an empty storageClass in the persistence will result in
kubernetes using your default storage class.
Please note, that an empty storageClass in the persistence will result in kubernetes using your default storage class.
If you want to use your own storageClass define it as followed:
If you want to use your own storage class define it as follows:
```yaml
persistence:
@ -362,8 +348,7 @@ persistence:
storageClass: myOwnStorageClass
```
When using PostgreSQL as dependency, this will also be deployed as a statefulset
by default.
When using PostgreSQL as dependency, this will also be deployed as a statefulset by default.
If you want to manage your own PVC you can simply pass the PVC name to the chart.
@ -387,10 +372,11 @@ postgresql:
### Admin User
This chart enables you to create a default admin user. It is also possible to
update the password for this user by upgrading or redeloying the chart. It is
not possible to delete an admin user after it has been created. This has to be
done in the ui. You cannot use `admin` as username.
This chart enables you to create a default admin user.
It is also possible to update the password for this user by upgrading or redeloying the chart.
It is not possible to delete an admin user after it has been created.
This has to be done in the ui.
You cannot use `admin` as username.
```yaml
gitea:
@ -443,7 +429,7 @@ gitea:
publicSSHKeyAttribute: publicSSHKey
```
You can also use an existing secret to set the bindDn and bindPassword:
You can also use an existing secret to set the `bindDn` and `bindPassword`:
```yaml
apiVersion: v1
@ -462,9 +448,9 @@ gitea:
- existingSecret: gitea-ldap-secret
```
⚠️ Some options are just flags and therefore don't have any values. If they
are defined in `gitea.ldap` configuration, they will be passed to the Gitea CLI
without any value. Affected options:
⚠️ Some options are just flags and therefore don't have any values.
If they are defined in `gitea.ldap` configuration, they will be passed to the Forgejo CLI without any value.
Affected options:
- notActive
- skipTlsVerify
@ -474,9 +460,9 @@ without any value. Affected options:
### OAuth2 Settings
Like the admin user, OAuth2 settings can be updated and disabled but not
deleted. Deleting OAuth2 settings has to be done in the ui. All OAuth2 values,
which are documented [here](https://docs.gitea.io/en-us/command-line/#admin), are
Like the admin user, OAuth2 settings can be updated and disabled but not deleted.
Deleting OAuth2 settings has to be done in the ui.
All OAuth2 values, which are documented [here](https://docs.gitea.io/en-us/command-line/#admin), are
available.
Multiple OAuth2 sources can be configured with additional OAuth list items.
@ -518,15 +504,12 @@ gitea:
## Configure commit signing
When using the rootless image the gpg key folder is not persistent by
default. If you consider using signed commits for internal Gitea activities
(e.g. initial commit), you'd need to provide a signing key. Prior to
[PR186](https://gitea.com/gitea/helm-chart/pulls/186), imported keys had to be
re-imported once the container got replaced by another.
When using the rootless image the gpg key folder is not persistent by default.
If you consider using signed commits for internal Forgejo activities (e.g. initial commit), you'd need to provide a signing key.
Prior to [PR186](https://gitea.com/gitea/helm-chart/pulls/186), imported keys had to be re-imported once the container got replaced by another.
The mentioned PR introduced a new configuration object `signing` allowing you to
configure prerequisites for commit signing. By default this section is disabled
to maintain backwards compatibility.
The mentioned PR introduced a new configuration object `signing` allowing you to configure prerequisites for commit signing.
By default this section is disabled to maintain backwards compatibility.
```yaml
signing:
@ -534,10 +517,8 @@ signing:
gpgHome: /data/git/.gnupg
```
Regardless of the used container image the `signing` object allows to specify a
private gpg key. Either using the `signing.privateKey` to define the key inline,
or refer to an existing secret containing the key data by using `signing.existingSecret`.
Regardless of the used container image the `signing` object allows to specify a private gpg key.
Either using the `signing.privateKey` to define the key inline, or refer to an existing secret containing the key data by using `signing.existingSecret`.
```yaml
apiVersion: v1
@ -557,19 +538,15 @@ signing:
existingSecret: custom-gitea-gpg-key
```
To use the gpg key, Gitea needs to be configured accordingly. A detailed description
can be found in the [official Gitea documentation](https://docs.gitea.io/en-us/signing/#general-configuration).
To use the gpg key, Forgejo needs to be configured accordingly.
A detailed description can be found in the [official Gitea documentation](https://docs.gitea.io/en-us/signing/#general-configuration).
### Metrics and profiling
A Prometheus `/metrics` endpoint on the `HTTP_PORT` and `pprof` profiling
endpoints on port 6060 can be enabled under `gitea`. Beware that the metrics
endpoint is exposed via the ingress, manage access using ingress annotations for
example.
A Prometheus `/metrics` endpoint on the `HTTP_PORT` and `pprof` profiling endpoints on port 6060 can be enabled under `gitea`.
Beware that the metrics endpoint is exposed via the ingress, manage access using ingress annotations for example.
To deploy the `ServiceMonitor`, you first need to ensure that you have deployed
`prometheus-operator` and its
[CRDs](https://github.com/prometheus-operator/prometheus-operator#customresourcedefinitions).
To deploy the `ServiceMonitor`, you first need to ensure that you have deployed `prometheus-operator` and its [CRDs](https://github.com/prometheus-operator/prometheus-operator#customresourcedefinitions).
```yaml
gitea:
@ -732,7 +709,7 @@ gitea:
| `gitea.additionalConfigSources` | Additional configuration from secret or configmap | `[]` |
| `gitea.additionalConfigFromEnvs` | Additional configuration sources from environment variables | `[]` |
| `gitea.podAnnotations` | Annotations for the Forgejo pod | `{}` |
| `gitea.ssh.logLevel` | Configure OpenSSH's log level. Only available for root-based Gitea image. | `INFO` |
| `gitea.ssh.logLevel` | Configure OpenSSH's log level. Only available for root-based Forgejo image. | `INFO` |
### LivenessProbe
@ -800,6 +777,7 @@ PostgreSQL is loaded as a dependency from [Bitnami](https://github.com/bitnami/c
| `test.enabled` | Set it to false to disable test-connection Pod. | `true` |
| `test.image.name` | Image name for the wget container used in the test-connection Pod. | `busybox` |
| `test.image.tag` | Image tag for the wget container used in the test-connection Pod. | `latest` |
| `extraDeploy` | Array of extra objects to deploy with the release | `[]` |
## Contributing

8
templates/gitea/extra-list.yaml Normal file
View file

@ -0,0 +1,8 @@
{{- range .Values.extraDeploy }}
---
{{- if typeIs "string" . }}
{{- tpl . $ }}
{{- else }}
{{- tpl (. | toYaml) $ }}
{{- end }}
{{- end }}

4
values.yaml
View file

@ -489,3 +489,7 @@ test:
image:
name: busybox
tag: latest
## @param extraDeploy Array of extra objects to deploy with the release
##
extraDeploy: []