mirror of
https://gitea.com/gitea/helm-chart.git
synced 2024-07-04 23:34:12 +02:00
README: one sentence per line (#440)
Fix #376 Editors should do the job of soft-wrapping in case a line get's too long. One sentence per line simplifies reviews and diffs a lot as it let's one comment on a piece of text that is contextually sound and not split over multiple lines. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/440 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>
This commit is contained in:
parent
0861260c5d
commit
c274911aab
290
README.md
290
README.md
@ -1,15 +1,13 @@
|
|||||||
# Gitea Helm Chart
|
# Gitea Helm Chart
|
||||||
|
|
||||||
[Gitea](https://gitea.io/en-us/) is a community managed lightweight code hosting
|
[Gitea](https://gitea.io/en-us/) is a community managed lightweight code hosting solution written in Go.
|
||||||
solution written in Go. It is published under the MIT license.
|
It is published under the MIT license.
|
||||||
|
|
||||||
## Introduction
|
## Introduction
|
||||||
|
|
||||||
This helm chart has taken some inspiration from [jfelten's helm
|
This helm chart has taken some inspiration from [jfelten's helm chart](https://github.com/jfelten/gitea-helm-chart).
|
||||||
chart](https://github.com/jfelten/gitea-helm-chart). But takes a completely
|
But takes a completely different approach in providing a database and cache with dependencies.
|
||||||
different approach in providing a database and cache with dependencies.
|
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
|
## Update and versioning policy
|
||||||
|
|
||||||
@ -29,9 +27,8 @@ Yet most often no issues will be encountered and the chart maintainers aim to co
|
|||||||
|
|
||||||
## Dependencies
|
## Dependencies
|
||||||
|
|
||||||
Gitea can be run with an external database and cache. This chart provides those
|
Gitea can be run with an external database and cache.
|
||||||
dependencies, which can be enabled, or disabled via
|
This chart provides those dependencies, which can be enabled, or disabled via configuration.
|
||||||
configuration.
|
|
||||||
|
|
||||||
Dependencies:
|
Dependencies:
|
||||||
|
|
||||||
@ -46,8 +43,7 @@ helm repo update
|
|||||||
helm install gitea gitea-charts/gitea
|
helm install gitea gitea-charts/gitea
|
||||||
```
|
```
|
||||||
|
|
||||||
When upgrading, please refer to the [Upgrading](#upgrading) section at the bottom
|
When upgrading, please refer to the [Upgrading](#upgrading) section at the bottom of this document for major and breaking changes.
|
||||||
of this document for major and breaking changes.
|
|
||||||
|
|
||||||
## Prerequisites
|
## Prerequisites
|
||||||
|
|
||||||
@ -59,8 +55,8 @@ of this document for major and breaking changes.
|
|||||||
|
|
||||||
### Gitea Configuration
|
### Gitea Configuration
|
||||||
|
|
||||||
Gitea offers lots of configuration options. This is fully described in the
|
Gitea offers lots of configuration options.
|
||||||
[Gitea Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/).
|
This is fully described in the [Gitea Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/).
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
gitea:
|
gitea:
|
||||||
@ -74,18 +70,17 @@ gitea:
|
|||||||
|
|
||||||
### Default Configuration
|
### Default Configuration
|
||||||
|
|
||||||
This chart will set a few defaults in the Gitea configuration based on the
|
This chart will set a few defaults in the Gitea configuration based on the service and ingress settings.
|
||||||
service and ingress settings. All defaults can be overwritten in `gitea.config`.
|
All defaults can be overwritten in `gitea.config`.
|
||||||
|
|
||||||
INSTALL_LOCK is always set to true, since we want to configure Gitea with this
|
INSTALL_LOCK is always set to true, since we want to configure Gitea with this helm chart and everything is taken care of.
|
||||||
helm chart and everything is taken care of.
|
|
||||||
|
|
||||||
_All default settings are made directly in the generated app.ini, not in the Values._
|
_All default settings are made directly in the generated app.ini, not in the Values._
|
||||||
|
|
||||||
#### Database defaults
|
#### Database defaults
|
||||||
|
|
||||||
If a builtIn database is enabled the database configuration is set
|
If a builtIn database is enabled the database configuration is set automatically.
|
||||||
automatically. For example, PostgreSQL builtIn will appear in the app.ini as:
|
For example, PostgreSQL builtIn will appear in the app.ini as:
|
||||||
|
|
||||||
```ini
|
```ini
|
||||||
[database]
|
[database]
|
||||||
@ -98,8 +93,8 @@ USER = gitea
|
|||||||
|
|
||||||
#### Memcached defaults
|
#### Memcached defaults
|
||||||
|
|
||||||
Memcached is handled the exact same way as database builtIn. Once Memcached
|
Memcached is handled the exact same way as database builtIn.
|
||||||
builtIn is enabled, this chart will generate the following part in the `app.ini`:
|
Once Memcached builtIn is enabled, this chart will generate the following part in the `app.ini`:
|
||||||
|
|
||||||
```ini
|
```ini
|
||||||
[cache]
|
[cache]
|
||||||
@ -110,9 +105,9 @@ HOST = RELEASE-NAME-memcached.default.svc.cluster.local:11211
|
|||||||
|
|
||||||
#### Server defaults
|
#### Server defaults
|
||||||
|
|
||||||
The server defaults are a bit more complex. If ingress is `enabled`, the
|
The server defaults are a bit more complex.
|
||||||
`ROOT_URL`, `DOMAIN` and `SSH_DOMAIN` will be set accordingly. `HTTP_PORT`
|
If ingress is `enabled`, the `ROOT_URL`, `DOMAIN` and `SSH_DOMAIN` will be set accordingly.
|
||||||
always defaults to `3000` as well as `SSH_PORT` to `22`.
|
`HTTP_PORT` always defaults to `3000` as well as `SSH_PORT` to `22`.
|
||||||
|
|
||||||
```ini
|
```ini
|
||||||
[server]
|
[server]
|
||||||
@ -141,14 +136,11 @@ ENABLED = false
|
|||||||
> **The [generic](https://docs.gitea.io/en-us/config-cheat-sheet/#overall-default)
|
> **The [generic](https://docs.gitea.io/en-us/config-cheat-sheet/#overall-default)
|
||||||
> section cannot be defined that way.**
|
> section cannot be defined that way.**
|
||||||
|
|
||||||
Some settings inside _app.ini_ (like passwords or whole authentication configurations)
|
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.
|
||||||
must be considered sensitive and therefore should not be passed via plain text
|
In times of _GitOps_ the values.yaml could be stored in a Git repository where sensitive data should never be accessible.
|
||||||
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
|
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
|
Kubernetes Secrets to be loaded as environment variables during _app.ini_ creation or update.
|
||||||
or update.
|
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
gitea:
|
gitea:
|
||||||
@ -161,8 +153,7 @@ gitea:
|
|||||||
|
|
||||||
This would mount the two additional volumes (`oauth` and `some-additionals`)
|
This would mount the two additional volumes (`oauth` and `some-additionals`)
|
||||||
from different sources to the init containerwhere the _app.ini_ gets updated.
|
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
|
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).
|
||||||
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 key of such additional source represents the section inside the _app.ini_.
|
||||||
The value for each key can be multiline ini-like definitions.
|
The value for each key can be multiline ini-like definitions.
|
||||||
@ -199,19 +190,15 @@ stringData:
|
|||||||
|
|
||||||
#### User defined environment variables in app.ini
|
#### User defined environment variables in app.ini
|
||||||
|
|
||||||
Users are able to define their own environment variables,
|
Users are able to define their own environment variables, which are loaded into the containers.
|
||||||
which are loaded into the containers. We also support to
|
We also support to directly interact with the generated _app.ini_.
|
||||||
directly interact with the generated _app.ini_.
|
|
||||||
|
|
||||||
To inject self defined variables into the _app.ini_ a
|
To inject self defined variables into the _app.ini_ a certain format needs to be honored.
|
||||||
certain format needs to be honored. This is
|
This is described in detail on the [env-to-ini](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini) page.
|
||||||
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`.
|
Note that the Prefix on this helm chart is `ENV_TO_INI`.
|
||||||
|
|
||||||
For example a database setting needs to have the following
|
For example a database setting needs to have the following format:
|
||||||
format:
|
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
gitea:
|
gitea:
|
||||||
@ -228,8 +215,8 @@ gitea:
|
|||||||
Priority (highest to lowest) for defining app.ini variables:
|
Priority (highest to lowest) for defining app.ini variables:
|
||||||
|
|
||||||
1. Environment variables prefixed with `ENV_TO_INI`
|
1. Environment variables prefixed with `ENV_TO_INI`
|
||||||
2. Additional config sources
|
1. Additional config sources
|
||||||
3. Values defined in `gitea.config`
|
1. Values defined in `gitea.config`
|
||||||
|
|
||||||
### External Database
|
### External Database
|
||||||
|
|
||||||
@ -255,7 +242,8 @@ postgresql:
|
|||||||
|
|
||||||
### Ports and external url
|
### 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
|
```yaml
|
||||||
service:
|
service:
|
||||||
@ -265,15 +253,14 @@ service:
|
|||||||
port: 22
|
port: 22
|
||||||
```
|
```
|
||||||
|
|
||||||
This helm chart automatically configures the clone urls to use the correct
|
This helm chart automatically configures the clone urls to use the correct ports.
|
||||||
ports. You can change these ports by hand using the `gitea.config` dict. However
|
You can change these ports by hand using the `gitea.config` dict.
|
||||||
you should know what you're doing.
|
However you should know what you're doing.
|
||||||
|
|
||||||
### ClusterIP
|
### ClusterIP
|
||||||
|
|
||||||
By default the clusterIP will be set to None, which is the default for headless
|
By default the `clusterIP` will be set to `None`, which is the default for headless services.
|
||||||
services. However if you want to omit the clusterIP field in the service, use
|
However if you want to omit the clusterIP field in the service, use the following values:
|
||||||
the following values:
|
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
service:
|
service:
|
||||||
@ -289,9 +276,8 @@ service:
|
|||||||
|
|
||||||
### SSH and Ingress
|
### SSH and Ingress
|
||||||
|
|
||||||
If you're using ingress and want to use SSH, keep in mind, that ingress is not
|
If you're using ingress and want to use SSH, keep in mind, that ingress is not able to forward SSH Ports.
|
||||||
able to forward SSH Ports. You will need a LoadBalancer like `metallb` and a
|
You will need a LoadBalancer like `metallb` and a setting in your ssh service annotations.
|
||||||
setting in your ssh service annotations.
|
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
service:
|
service:
|
||||||
@ -302,8 +288,8 @@ service:
|
|||||||
|
|
||||||
### SSH on crio based kubernetes cluster
|
### SSH on crio based kubernetes cluster
|
||||||
|
|
||||||
If you use crio as container runtime it is not possible to read from a remote
|
If you use `crio` as container runtime it is not possible to read from a remote repository.
|
||||||
repository. You should get an error message like this:
|
You should get an error message like this:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
$ git clone git@k8s-demo.internal:admin/test.git
|
$ git clone git@k8s-demo.internal:admin/test.git
|
||||||
@ -320,15 +306,15 @@ More about this issue [here](https://gitea.com/gitea/helm-chart/issues/161).
|
|||||||
|
|
||||||
### Cache
|
### 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
|
```yaml
|
||||||
memcached:
|
memcached:
|
||||||
enabled: true
|
enabled: true
|
||||||
```
|
```
|
||||||
|
|
||||||
If the built in cache should not be used simply configure the cache in
|
If the built in cache should not be used simply configure the cache in `gitea.config`.
|
||||||
`gitea.config`.
|
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
gitea:
|
gitea:
|
||||||
@ -342,15 +328,14 @@ gitea:
|
|||||||
|
|
||||||
### Persistence
|
### Persistence
|
||||||
|
|
||||||
Gitea will be deployed as a statefulset. By simply enabling the persistence and
|
Gitea will be deployed as a statefulset.
|
||||||
setting the storage class according to your cluster everything else will be
|
By simply enabling the persistence and setting the storage class according to your cluster everything else will be taken care of.
|
||||||
taken care of. The following example will create a PVC as a part of the
|
The following example will create a PVC as a part of the statefulset.
|
||||||
statefulset. This PVC will not be deleted even if you uninstall the chart.
|
This PVC will not be deleted even if you uninstall the chart.
|
||||||
|
|
||||||
Please note, that an empty storageClass in the persistence will result in
|
Please note, that an empty storageClass in the persistence will result in kubernetes using your default storage class.
|
||||||
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
|
```yaml
|
||||||
persistence:
|
persistence:
|
||||||
@ -358,8 +343,7 @@ persistence:
|
|||||||
storageClass: myOwnStorageClass
|
storageClass: myOwnStorageClass
|
||||||
```
|
```
|
||||||
|
|
||||||
When using PostgreSQL as dependency, this will also be deployed as a statefulset
|
When using PostgreSQL as dependency, this will also be deployed as a statefulset by default.
|
||||||
by default.
|
|
||||||
|
|
||||||
If you want to manage your own PVC you can simply pass the PVC name to the chart.
|
If you want to manage your own PVC you can simply pass the PVC name to the chart.
|
||||||
|
|
||||||
@ -383,10 +367,11 @@ postgresql:
|
|||||||
|
|
||||||
### Admin User
|
### Admin User
|
||||||
|
|
||||||
This chart enables you to create a default admin user. It is also possible to
|
This chart enables you to create a default admin user.
|
||||||
update the password for this user by upgrading or redeloying the chart. It is
|
It is also possible to update the password for this user by upgrading or redeloying the chart.
|
||||||
not possible to delete an admin user after it has been created. This has to be
|
It is not possible to delete an admin user after it has been created.
|
||||||
done in the ui. You cannot use `admin` as username.
|
This has to be done in the ui.
|
||||||
|
You cannot use `admin` as username.
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
gitea:
|
gitea:
|
||||||
@ -439,7 +424,7 @@ gitea:
|
|||||||
publicSSHKeyAttribute: publicSSHKey
|
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
|
```yaml
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
@ -459,9 +444,9 @@ gitea:
|
|||||||
...
|
...
|
||||||
```
|
```
|
||||||
|
|
||||||
⚠️ Some options are just flags and therefore don't have any values. If they
|
⚠️ Some options are just flags and therefore don't have any values.
|
||||||
are defined in `gitea.ldap` configuration, they will be passed to the Gitea CLI
|
If they are defined in `gitea.ldap` configuration, they will be passed to the Gitea CLI without any value.
|
||||||
without any value. Affected options:
|
Affected options:
|
||||||
|
|
||||||
- notActive
|
- notActive
|
||||||
- skipTlsVerify
|
- skipTlsVerify
|
||||||
@ -471,9 +456,9 @@ without any value. Affected options:
|
|||||||
|
|
||||||
### OAuth2 Settings
|
### OAuth2 Settings
|
||||||
|
|
||||||
Like the admin user, OAuth2 settings can be updated and disabled but not
|
Like the admin user, OAuth2 settings can be updated and disabled but not deleted.
|
||||||
deleted. Deleting OAuth2 settings has to be done in the ui. All OAuth2 values,
|
Deleting OAuth2 settings has to be done in the ui.
|
||||||
which are documented [here](https://docs.gitea.io/en-us/command-line/#admin), are
|
All OAuth2 values, which are documented [here](https://docs.gitea.io/en-us/command-line/#admin), are
|
||||||
available.
|
available.
|
||||||
|
|
||||||
Multiple OAuth2 sources can be configured with additional OAuth list items.
|
Multiple OAuth2 sources can be configured with additional OAuth list items.
|
||||||
@ -516,15 +501,12 @@ gitea:
|
|||||||
|
|
||||||
## Configure commit signing
|
## Configure commit signing
|
||||||
|
|
||||||
When using the rootless image the gpg key folder is not persistent by
|
When using the rootless image the gpg key folder is not persistent by default.
|
||||||
default. If you consider using signed commits for internal Gitea activities
|
If you consider using signed commits for internal Gitea activities (e.g. initial commit), you'd need to provide a signing key.
|
||||||
(e.g. initial commit), you'd need to provide a signing key. Prior to
|
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.
|
||||||
[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
|
The mentioned PR introduced a new configuration object `signing` allowing you to configure prerequisites for commit signing.
|
||||||
configure prerequisites for commit signing. By default this section is disabled
|
By default this section is disabled to maintain backwards compatibility.
|
||||||
to maintain backwards compatibility.
|
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
signing:
|
signing:
|
||||||
@ -532,9 +514,8 @@ signing:
|
|||||||
gpgHome: /data/git/.gnupg
|
gpgHome: /data/git/.gnupg
|
||||||
```
|
```
|
||||||
|
|
||||||
Regardless of the used container image the `signing` object allows to specify a
|
Regardless of the used container image the `signing` object allows to specify a private gpg key.
|
||||||
private gpg key. Either using the `signing.privateKey` to define the key inline,
|
Either using the `signing.privateKey` to define the key inline, or refer to an existing secret containing the key data by using `signing.existingSecret`.
|
||||||
or refer to an existing secret containing the key data by using `signing.existingSecret`.
|
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
@ -554,19 +535,15 @@ signing:
|
|||||||
existingSecret: custom-gitea-gpg-key
|
existingSecret: custom-gitea-gpg-key
|
||||||
```
|
```
|
||||||
|
|
||||||
To use the gpg key, Gitea needs to be configured accordingly. A detailed description
|
To use the gpg key, Gitea needs to be configured accordingly.
|
||||||
can be found in the [official Gitea documentation](https://docs.gitea.io/en-us/signing/#general-configuration).
|
A detailed description can be found in the [official Gitea documentation](https://docs.gitea.io/en-us/signing/#general-configuration).
|
||||||
|
|
||||||
### Metrics and profiling
|
### Metrics and profiling
|
||||||
|
|
||||||
A Prometheus `/metrics` endpoint on the `HTTP_PORT` and `pprof` profiling
|
A Prometheus `/metrics` endpoint on the `HTTP_PORT` and `pprof` profiling endpoints on port 6060 can be enabled under `gitea`.
|
||||||
endpoints on port 6060 can be enabled under `gitea`. Beware that the metrics
|
Beware that the metrics endpoint is exposed via the ingress, manage access using ingress annotations for example.
|
||||||
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
|
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).
|
||||||
`prometheus-operator` and its
|
|
||||||
[CRDs](https://github.com/prometheus-operator/prometheus-operator#customresourcedefinitions).
|
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
gitea:
|
gitea:
|
||||||
@ -831,26 +808,21 @@ See [Configure commit signing](#configure-commit-signing) for details.
|
|||||||
|
|
||||||
#### Different volume mounts for init-containers and runtime container
|
#### Different volume mounts for init-containers and runtime container
|
||||||
|
|
||||||
**The `extraVolumeMounts` is deprecated** in favor of `extraInitVolumeMounts` and
|
**The `extraVolumeMounts` is deprecated** in favor of `extraInitVolumeMounts` and `extraContainerVolumeMounts`.
|
||||||
`extraContainerVolumeMounts`. You can now have different mounts for the initialization
|
You can now have different mounts for the initialization phase and Gitea runtime.
|
||||||
phase and Gitea runtime. The deprecated `extraVolumeMounts` will still be available
|
The deprecated `extraVolumeMounts` will still be available for the time being and is mounted into every container.
|
||||||
for the time being and is mounted into every container. If you want to switch to
|
If you want to switch to the new settings and want to mount specific volumes into all containers, you have to configure their mount points within both new settings.
|
||||||
the new settings and want to mount specific volumes into all containers, you have
|
|
||||||
to configure their mount points within both new settings.
|
|
||||||
|
|
||||||
**Combining values from the deprecated setting with values from the new settings
|
**Combining values from the deprecated setting with values from the new settings is not possible.**
|
||||||
is not possible.**
|
|
||||||
|
|
||||||
#### New `enabled` flag for `startupProbe`
|
#### New `enabled` flag for `startupProbe`
|
||||||
|
|
||||||
Prior to this version the `startupProbe` was just a commented sample within the
|
Prior to this version the `startupProbe` was just a commented sample within the `values.yaml`.
|
||||||
`values.yaml`. With the migration to an auto-generated [Parameters](#parameters)
|
With the migration to an auto-generated [Parameters](#parameters) section, a new parameter `gitea.startupProbe.enabled` has been introduced set to
|
||||||
section, a new parameter `gitea.startupProbe.enabled` has been introduced set to
|
|
||||||
`false` by default.
|
`false` by default.
|
||||||
|
|
||||||
If you are using the `startupProbe` you need to add that new
|
If you are using the `startupProbe` you need to add that new parameter and set it to `true`.
|
||||||
parameter and set it to `true`. Otherwise, your defined probe won't be considered
|
Otherwise, your defined probe won't be considered after the upgrade.
|
||||||
after the upgrade.
|
|
||||||
|
|
||||||
### To 5.0.0
|
### To 5.0.0
|
||||||
|
|
||||||
@ -858,9 +830,7 @@ after the upgrade.
|
|||||||
|
|
||||||
#### Enable Dependencies
|
#### Enable Dependencies
|
||||||
|
|
||||||
The values to enable the dependencies,
|
The values to enable the dependencies, such as PostgreSQL, Memcached, MySQL and MariaDB have been moved from `gitea.database.builtIn.` to the dependency values.
|
||||||
such as PostgreSQL, Memcached, MySQL and MariaDB.
|
|
||||||
have been moved from `gitea.database.builtIn.` to the dependency values.
|
|
||||||
|
|
||||||
You can now enable the dependencies as followed:
|
You can now enable the dependencies as followed:
|
||||||
|
|
||||||
@ -880,39 +850,32 @@ mariadb:
|
|||||||
|
|
||||||
#### App.ini generation
|
#### App.ini generation
|
||||||
|
|
||||||
The app.ini generation has changed and now utilizes the environment-to-ini
|
The app.ini generation has changed and now utilizes the environment-to-ini script provided by newer Gitea versions.
|
||||||
script provided by newer Gitea versions. This change ensures, that the app.ini
|
This change ensures, that the app.ini is now persistent.
|
||||||
is now persistent.
|
|
||||||
|
|
||||||
##### Secret Key generation
|
##### Secret Key generation
|
||||||
|
|
||||||
Gitea secret keys (SECRET_KEY, INTERNAL_TOKEN, JWT_SECRET) are now generated
|
Gitea secret keys (SECRET_KEY, INTERNAL_TOKEN, JWT_SECRET) are now generated automatically in certain situations:
|
||||||
automatically in certain situations:
|
|
||||||
|
|
||||||
- New install: By default the secrets are created automatically. If you provide
|
- New install: By default the secrets are created automatically.
|
||||||
secrets via `gitea.config` they will be used instead of automatic generation.
|
If you provide secrets via `gitea.config` they will be used instead of automatic generation.
|
||||||
- Existing installs: The secrets won't be deployed, neither via
|
- Existing installs: The secrets won't be deployed, neither via configuration nor via auto generation.
|
||||||
configuration nor via auto generation. We explicitly prevent to set new secrets.
|
We explicitly prevent to set new secrets.
|
||||||
|
|
||||||
> 💡 It would be possible to set new secret keys manually by entering
|
> 💡 It would be possible to set new secret keys manually by entering the running container and rewriting the app.ini by hand.
|
||||||
> the running container and rewriting the app.ini by hand. However, this it is
|
> However, this it is not advisable to do so for existing installations.
|
||||||
> not advisable to do so for existing installations. Certain settings like
|
> Certain settings like _LDAP_ would not be readable anymore.
|
||||||
> _LDAP_ would not be readable anymore.
|
|
||||||
|
|
||||||
#### Probes
|
#### Probes
|
||||||
|
|
||||||
`gitea.customLivenessProbe`, `gitea.customReadinessProbe` and `gitea.customStartupProbe`
|
`gitea.customLivenessProbe`, `gitea.customReadinessProbe` and `gitea.customStartupProbe` have been removed.
|
||||||
have been removed.
|
|
||||||
|
|
||||||
They are replaced by the settings `gitea.livenessProbe`, `gitea.readinessProbe`
|
They are replaced by the settings `gitea.livenessProbe`, `gitea.readinessProbe` and `gitea.startupProbe` which are now fully configurable and used _as-is_ for
|
||||||
and `gitea.startupProbe` which are now fully configurable and used _as-is_ for
|
|
||||||
a Chart deployment.
|
a Chart deployment.
|
||||||
If you have customized their values instead of using the `custom` prefixed settings,
|
If you have customized their values instead of using the `custom` prefixed settings, please ensure that you remove the `enabled` property from each of them.
|
||||||
please ensure that you remove the `enabled` property from each of them.
|
|
||||||
|
|
||||||
In case you want to disable one of these probes, let's say the `livenessProbe`, add
|
In case you want to disable one of these probes, let's say the `livenessProbe`, add the following to your values.
|
||||||
the following to your values. The `podAnnotation` is just there to have a bit more
|
The `podAnnotation` is just there to have a bit more context.
|
||||||
context.
|
|
||||||
|
|
||||||
```diff
|
```diff
|
||||||
gitea:
|
gitea:
|
||||||
@ -922,20 +885,17 @@ gitea:
|
|||||||
|
|
||||||
#### Multiple OAuth and LDAP authentication sources
|
#### Multiple OAuth and LDAP authentication sources
|
||||||
|
|
||||||
With `5.0.0` of this Chart it is now possible to configure Gitea with multiple
|
With `5.0.0` of this Chart it is now possible to configure Gitea with multiple OAuth and LDAP sources.
|
||||||
OAuth and LDAP sources. As a result, you need to update an existing OAuth/LDAP configuration
|
As a result, you need to update an existing OAuth/LDAP configuration in your customized `values.yaml` by replacing the object with settings to a list
|
||||||
in your customized `values.yaml` by replacing the object with settings to a list
|
of settings objects.
|
||||||
of settings objects. See [OAuth2 Settings](#oauth2-settings) and
|
See [OAuth2 Settings](#oauth2-settings) and [LDAP Settings](#ldap-settings) section for details.
|
||||||
[LDAP Settings](#ldap-settings) section for details.
|
|
||||||
|
|
||||||
### To 4.0.0
|
### To 4.0.0
|
||||||
|
|
||||||
#### Ingress changes
|
#### Ingress changes
|
||||||
|
|
||||||
To provide a more flexible Ingress configuration we now support not only host
|
To provide a more flexible Ingress configuration we now support not only host settings but also provide configuration for the path and pathType.
|
||||||
settings but also provide configuration for the path and pathType. So this
|
So this change changes the hosts from a simple string list, to a list containing a more complex object for more configuration.
|
||||||
change changes the hosts from a simple string list, to a list containing a more
|
|
||||||
complex object for more configuration.
|
|
||||||
|
|
||||||
```diff
|
```diff
|
||||||
ingress:
|
ingress:
|
||||||
@ -956,8 +916,7 @@ ingress:
|
|||||||
# - git.example.com
|
# - git.example.com
|
||||||
```
|
```
|
||||||
|
|
||||||
If you want everything as it was before, you can simply add the following code
|
If you want everything as it was before, you can simply add the following code to all your host entries.
|
||||||
to all your host entries.
|
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
paths:
|
paths:
|
||||||
@ -967,41 +926,34 @@ paths:
|
|||||||
|
|
||||||
#### Dropped kebab-case support
|
#### Dropped kebab-case support
|
||||||
|
|
||||||
In 3.x.x it was possible to provide an ldap configuration via kebab-case, this
|
In 3.x.x it was possible to provide an ldap configuration via kebab-case, this support has now been dropped and only camel case is supported.
|
||||||
support has now been dropped and only camel case is supported. See [LDAP
|
See [LDAP section](#ldap-settings) for more information.
|
||||||
section](#ldap-settings) for more information.
|
|
||||||
|
|
||||||
#### Dependency update
|
#### Dependency update
|
||||||
|
|
||||||
The chart comes with multiple databases and Memcached as dependency, the latest
|
The chart comes with multiple databases and Memcached as dependency, the latest release updated the dependencies.
|
||||||
release updated the dependencies.
|
|
||||||
|
|
||||||
- Memcached: `4.2.20` -> `5.9.0`
|
- Memcached: `4.2.20` -> `5.9.0`
|
||||||
- PostgreSQL: `9.7.2` -> `10.3.17`
|
- PostgreSQL: `9.7.2` -> `10.3.17`
|
||||||
- MariaDB: `8.0.0` -> `9.3.6`
|
- MariaDB: `8.0.0` -> `9.3.6`
|
||||||
|
|
||||||
If you're using the builtin databases you will most likely redeploy the chart in
|
If you're using the builtin databases you will most likely redeploy the chart in order to update the database correctly.
|
||||||
order to update the database correctly.
|
|
||||||
|
|
||||||
#### Execution of initPreScript
|
#### Execution of initPreScript
|
||||||
|
|
||||||
Generally spoken, this might not be a breaking change, but it is worth to be
|
Generally spoken, this might not be a breaking change, but it is worth to be mentioned.
|
||||||
mentioned.
|
|
||||||
|
|
||||||
Prior to `4.0.0` only one init container was used to both setup directories and
|
Prior to `4.0.0` only one init container was used to both setup directories and configure Gitea.
|
||||||
configure Gitea. As of now the actual Gitea configuration is separated from the
|
As of now the actual Gitea configuration is separated from the other pre-execution.
|
||||||
other pre-execution. This also includes the execution of _initPreScript_. If you
|
This also includes the execution of _initPreScript_.
|
||||||
have such script, please be aware of this. Dynamically prepare the Gitea setup
|
If you have such script, please be aware of this.
|
||||||
during execution by e.g. adding environment variables to the execution context
|
Dynamically prepare the Gitea setup during execution by e.g. adding environment variables to the execution context won't work anymore.
|
||||||
won't work anymore.
|
|
||||||
|
|
||||||
### Misc
|
### Misc
|
||||||
|
|
||||||
#### Gitea Version 1.14.X repository ROOT
|
#### Gitea Version 1.14.X repository ROOT
|
||||||
|
|
||||||
Previously the ROOT folder for the Gitea repositories was located at
|
Previously the ROOT folder for the Gitea repositories was located at `/data/git/gitea-repositories`.
|
||||||
`/data/git/gitea-repositories`. In version `1.14` has the path been changed to
|
In version `1.14` has the path been changed to `/data/gitea-repositories`.
|
||||||
`/data/gitea-repositories`.
|
|
||||||
|
|
||||||
This chart will set the `gitea.config.repository.ROOT` value default to
|
This chart will set the `gitea.config.repository.ROOT` value default to `/data/git/gitea-repositories`.
|
||||||
`/data/git/gitea-repositories`.
|
|
||||||
|
Loading…
Reference in New Issue
Block a user