marko/Gitea-HelmChart
1
0
Fork 0
mirror of https://gitea.com/gitea/helm-chart.git synced 2024-07-02 14:30:35 +02:00
Code Issues Packages Projects Releases Wiki Activity

README: one sentence per line (#440)

Browse Source 
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:
pat-s 2023-04-19 23:01:03 +08:00 committed by justusbunsi
parent 0861260c5d
commit c274911aab
1 changed files with 121 additions and 169 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

290
README.md
View File

@ -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`.