### Description of the change
Before only `postgresql-ha` was auto-configured WRT to DNS.
### Benefits
Add DNS auto-config for `postgresql` dependency and assert that either `postgresql` or `postgresql-ha` is enabled.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/478
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
### Description of the change
Update default params of chart dependencies. Tested with multiple upgrades and fresh installations.
Using no password auth for redis simplifies things for basic installations. Production installations should properly configure auth as they need it.
### Benefits
To avoid/solve upgrading issues as in #407 and #472
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/473
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
<!--
Before you open the request please review the following guidelines and tips to help it be more easily integrated:
- Describe the scope of your change - i.e. what the change does.
- Describe any known limitations with your change.
- Please run any tests or examples that can exercise your modified code.
Thank you for contributing! We will try to review, test and integrate the change as soon as we can.
-->
### Description of the change
<!-- Describe the scope of your change - i.e. what the change does. -->
remove deployment, `serviceName`
### Benefits
<!-- What benefits will be realized by the code change? -->
### Possible drawbacks
<!-- Describe any known limitations with your change -->
### Applicable issues
<!-- Enter any applicable Issues here (You can reference an issue using #). Please remove this section if there is no referenced issue. -->
- fixes#466
### Additional information
<!-- If there's anything else that's important and relevant to your pull request, mention that information here. Please remove this section if it remains empty. -->
### ⚠ BREAKING
<!-- If there's a breaking change, please shortly describe in which way users are affected and how they can mitigate it. If there are no breakings, please remove this section. -->
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [x] Breaking changes are documented in the `README.md`
- [x] Templating unittests are added
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/467
Co-authored-by: yinheli <me@yinheli.com>
Co-committed-by: yinheli <me@yinheli.com>
# Changes
A big shoutout to @luhahn for all his work in #205 which served as the base for this PR.
## Documentation
- [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long).
Most of the information below should go into it with more details and explanations behind all of the individual components.
## Chart deps
~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~
~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~
- Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2.
- Removes `memcached` instead of `redis-cluster`
- Add `postgresql-ha` as default DB dep in favor of `postgres`
## Adds smart HA chart logic
The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1.
- If `replicaCount` > 1,
- `gitea.config.session.PROVIDER` is automatically set to `redis-cluster`
- `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch`
- `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not
Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc.
## Deployment vs Statefulset
Given all the discussions about this lately (#428), I think we could use both.
In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets.
On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment.
Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption.
Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case.
This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet.
The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way?
## Chart PVC Creation
I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation.
In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial.
A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse...
- New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim`
- New `persistence.create`: whether to create a new PVC
## Testing
As this PR does a lot of things, we need proper testing.
The helm chart can be installed from the Git branch via `helm-git` as follows:
```
helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment
helm install gitea --version 0.0.0
```
It is **highly recommended** to test the chart in a dedicated namespace.
I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine.
I just did some basic operations though and we should do more niche testing before merging.
Examplary `values.yml` for testing (only needs a valid RWX storage class):
<details>
<summary>values.yaml</summary>
```yml
image:
tag: "dev"
PullPolicy: "Always"
rootless: true
replicaCount: 2
persistence:
enabled: true
accessModes:
- ReadWriteMany
storageClass: FIXME
redis-cluster:
enabled: false
global:
redis:
password: gitea
gitea:
config:
indexer:
ISSUE_INDEXER_ENABLED: true
REPO_INDEXER_ENABLED: false
```
</details>
## Preferred setup
The preferred HA setup with respect to performance and stability might currently be as follows:
- Repos: RWX (e.g. EFS or Azurefiles NFS)
- Issue indexer: Meilisearch (HA)
- Session and cache: Redis Cluster (HA)
- Attachments/Avatars: Minio (HA)
This will result in a ~ 10-pod HA setup overall.
All pods have very low resource requests.
fix#98
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
<!--
Before you open the request please review the following guidelines and tips to help it be more easily integrated:
- Describe the scope of your change - i.e. what the change does.
- Describe any known limitations with your change.
- Please run any tests or examples that can exercise your modified code.
Thank you for contributing! We will try to review, test and integrate the change as soon as we can.
-->
### Description of the change
Add documentation how to add custom themes
### Benefits
<!-- What benefits will be realized by the code change? -->
### Possible drawbacks
<!-- Describe any known limitations with your change -->
### Applicable issues
<!-- Enter any applicable Issues here (You can reference an issue using #). Please remove this section if there is no referenced issue. -->
- fixes#301
### Additional information
<!-- If there's anything else that's important and relevant to your pull request, mention that information here. Please remove this section if it remains empty. -->
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [x] Breaking changes are documented in the `README.md`
- [x] Templating unittests are added
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/460
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
### Description of the change
- Add ToC to README for easier navigation (and add note to `contributing.md`)
- Fix some heading levels in README
- Put upgrading notes into collapsible blocks
- Format `contributing.md` according to MD rules
- Allow `details` and `summary` elements in README
- Allow for longer headings
### Benefits
Better documentation
### Possible drawbacks
None
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/461
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
### Description of the change
This adds a new values object `serviceAccount`, that allows creating a dedicated ServiceAccount with the Helm Release into the cluster. It supports all common options like labels, annotations, name override (or referring to an externally created ServiceAccount), auto-mount token, image pull secrets.
It supersedes the stale PR #357.
### Benefits
Users can deploy Gitea with more fine-tuned security settings.
### Applicable issues
- related to #448
### Additional information
I've bumped the helm-unittest plugin in the CI build, to be able to use the `exists` and `notExists` feature in the new tests.
### Checklist
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/451
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Signed-off-by: Cyril Jouve <jv.cyril@gmail.com>
<!--
Before you open the request please review the following guidelines and tips to help it be more easily integrated:
- Describe the scope of your change - i.e. what the change does.
- Describe any known limitations with your change.
- Please run any tests or examples that can exercise your modified code.
Thank you for contributing! We will try to review, test and integrate the change as soon as we can.
-->
### Description of the change
<!-- Describe the scope of your change - i.e. what the change does. -->
add a new value `extraDeploy` to add arbitrary resources
inspired by bitnami charts ([example](https://github.com/bitnami/charts/blob/main/bitnami/postgresql/values.yaml#L58)
### Benefits
<!-- What benefits will be realized by the code change? -->
with the change, I can deploy additional resources and keep them consistent with the chart (reuse macro, same labels, etc)., same workflow (helm upgrade), etc
### Possible drawbacks
<!-- Describe any known limitations with your change -->
### Additional information
<!-- If there's anything else that's important and relevant to your pull request, mention that information here. Please remove this section if it remains empty. -->
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/441
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: Cyril Jouve <jv.cyril@gmail.com>
Co-committed-by: Cyril Jouve <jv.cyril@gmail.com>
### Description of the change
Fix a wrong reference to `signing.existingKey`, `signing.existingSecret` was what was meant and what is used in the chart.
### Benefits
Less confusion when trying to use the Helm chart.
### Possible drawbacks
Evangelists of `existingKey` storming the barricades even though `existingKey` is long dead.
### Applicable issues
None, nobody noticed enough to care, apparently.
Co-authored-by: Tobias Wolter <towo@towo.eu>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/415
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: towo <towo@noreply.gitea.io>
Co-committed-by: towo <towo@noreply.gitea.io>
### Description of the change
Corrects the spelling of the word deprecated.
### Benefits
Documentation free of misspelled words is more likely to be viewed as "professional".
### Possible drawbacks
None that I can think of
### Applicable issues
- fixes#393
### Additional information
There may be other misspelled words or incorrectly phrased passages that aren't addressed in this PR.
For reference, see the online dictionary for the correct spelling of deprecated.
https://www.merriam-webster.com/dictionary/deprecated
### Checklist
- [X] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [X] Breaking changes are documented in the `README.md`
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/394
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: robv89r <robv8r@noreply.gitea.io>
Co-committed-by: robv89r <robv8r@noreply.gitea.io>
<!--
Before you open the request please review the following guidelines and tips to help it be more easily integrated:
- Describe the scope of your change - i.e. what the change does.
- Describe any known limitations with your change.
- Please run any tests or examples that can exercise your modified code.
Thank you for contributing! We will try to review, test and integrate the change as soon as we can.
-->
### Description of the change
Exluding non helm chart related files from release artifact
### Benefits
Smaller release artifacts
### Possible drawbacks
Exluded files not visible any within the artifact
### Applicable issues
None
### Additional information
None
### ⚠ BREAKING
None
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [x] Breaking changes are documented in the `README.md`
Co-authored-by: Julian Schlarb <js@project-deadline.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/385
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Co-authored-by: JSchlarb <jschlarb@noreply.gitea.io>
Co-committed-by: JSchlarb <jschlarb@noreply.gitea.io>
### Description of the change
This PR adds support for gpg key setup. It allows to pass the gpg private key content inline inside `values.yaml` or refer to an existing secret containing the key content data.
### Benefits
Administrators don't need to manually setup the gpg environment from inside a running container. It also eliminates the breaking change of Gitea 1.17 regarding `[git].HOME` as the `GNUPGHOME` environment variable is used consistently to relocate the `.gnupg` directory to its former location.
### Applicable issues
- fixes#107
### Additional information
This PR add the first unit tests to this Helm Chart, ensuring templating integrity for signing related configuration.
### Checklist
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/343
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
### Description of the change
Checking the existence of the config directory should be done with the directory path itself. Not its parent directory.
This simple fix addresses that by using the config directory for its existence check.
### Benefits
Prior to #337 there was no other way to install this helm chart using the `extraVolumeMounts` setting with these values:
```yaml
replicaCount: %d
extraVolumes:
- name: config-volume
configMap:
name: %s
extraVolumeMounts:
- name: config-volume
mountPath: /data/gitea/templates/custom
```
Without this fix, the Gitea pod would never initialize, and would crashloop with the same error in #296.
### Additional information
Mounting a configMap to `/data/gitea/templates/custom` causes the `/data/gitea` folder to exist even though the `/data/gitea/conf` had not been initialized yet. The initialization script saw that the `/data/gitea` dir existed and exited early without initializing `/data/gitea/conf`.
Co-authored-by: cboin1996 <christianboin@hotmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/310
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Co-authored-by: cboin1996 <cboin1996@noreply.gitea.io>
Co-committed-by: cboin1996 <cboin1996@noreply.gitea.io>
Description of the change
Mostly, this change just moves the changelog to the bottom of the README which helps new users to see the actual documentation. As the structure for the changes itself is slightly different, there are some changes in wording so that it still makes sense. But mostly structural changes.
The change within the dependency section is due to a broken link since auto-generating the parameters section. Now there are links to every dependency related parameters.
Benefits
It helps us to maintain a clear structure for the README of this project.
Possible drawbacks
Our users are currently trained to look at the top of the document to see the changes. They now have to scroll down or use the quick link from installation section.
Applicable issues
fixes#247
Additional information
Every version section starts with a disclaimer right now. This is duplicated and might hide important text due to its existence. A centralized intruduction at top of the upgrading section tells the reader what to expect from that whole section.
I've also noticed that on ArtifactHub the emotes are not rendered correctly. So I replaced them with the actual ones and reduced their usage. That way it better highlights those parts the reader must not miss.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/331
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>
Before you open the request please review the following guidelines and tips to help it be more easily integrated:
-Describe the scope of your change - i.e. what the change does.
-Describe any known limitations with your change.
-Please run any tests or examples that can exercise your modified code.
Thank you for contributing! We will try to review, test and integrate the change as soon as we can.
-->
### Description of the change
<!-- Describe the scope of your change - i.e. what the change does. -->
### Benefits
<!-- What benefits will be realized by the code change? -->
### Possible drawbacks
<!-- Describe any known limitations with your change -->
### Applicable issues
<!-- Enter any applicable Issues here (You can reference an issue using #). Please remove this section if there is no referenced issue. -->
- fixes #
### Additional information
<!-- If there's anything else that's important and relevant to your pull request, mention that information here. Please remove this section if it remains empty. -->
### ⚠ BREAKING
<!-- If there's a breaking change, please shortly describe in which way users are affected and how they can mitigate it. If there are no breakings, please remove this section. -->
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [ ] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [ ] Breaking changes are documented in the `README.md`
The `README.md` must include all configuration options.
The parameters section is generated by extracting the parameter annotations from the `values.yaml` file, by using [this tool](https://github.com/bitnami-labs/readme-generator-for-helm).
If changes were made on configuration options, run `make readme` to update the README file.
The ToC is created via the VSCode [Markdown All in One](https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one) extension which can/must also be used used to update it.
## Pull Request Requirements
When submitting or updating a PR:
- make sure it passes CI builds.
- do not make independent changes in one PR.
- try to avoid rebases. They make code reviews for large PRs and comments much harder.
- if applicable, use the PR template for a well-defined PR description.
- clearly mark breaking changes.
## Local development & testing
For local development and testing of pull requests, the following workflow can
be used:
1. Install `minikube` and `helm`.
1. Start a `minikube` cluster via `minikube start`.
1. From the `gitea/helm-chart` directory execute the following command.
This will install the dependencies listed in `Chart.yml` and deploy the current state of the helm chart found locally.
If you want to test a branch, make sure to switch to the respective branch first.
All components (in-memory DB, volume/asset storage, code indexer) used by Gitea must be deployed in a HA-ready fashion to achieve a full HA-ready Gitea deployment.
The following document explains how to achieve this for all individual components.
The resulting Gitea deployment will consist of ~ 10 pods (depending on the chosen components and their replicas).
One should evaluate upfront whether a HA-deployment is required as switching between HA/non-HA comes with some effort.
For production instances, HA is always recommended to increase uptime and have a frictionless update process.
A general comment about chart dependencies and external services:
Instead of relying on chart dependencies, it is often better to rely on an external, (managed) instances (in-memory database, asset storage provider, database, etc.).
Many cloud providers offer such services, at least for databases or in-memory databases.
They might cost a bit more than using a self-hosted k8s variant but are usually easier to maintain and scale, if needed.
Also they can be centrally managed and are not linked to the Gitea helm chart or namespace.
Please consider using external services before you start with your Gitea HA setup, it will make your life (and the life of the Gitea maintainers) easier.
This helm chart tries to help as much as possible to simplify and assert the provisioning of a HA-ready Gitea instance by implementing smart conditionals if `replicaCount` is set to a value > 1.
Nevertheless, we cannot guarantee for every possible combination of Gitea settings to work together perfectly in a HA setup.
As a general advice, we recommend to have a test environment aside on which to test possible changes/upgrades before applying these to a production installation.
## Requirements for HA
Storage-wise, the HA-Gitea setup requires a RWX file-system which can be shared among the deployment-based replica pods.
In addition, the following components are required for full HA-readiness:
- A HA-ready issue (and optionally code) indexer: `elasticsearch` or `meilisearch`
- A HA-ready external object/asset storage (`minio`) (optional, assets can also be stored on the RWX file-system)
- A HA-ready cache (`redis-cluster`)
- A HA-ready DB
`postgres.enabled`, which default to `true`, must be set to `false` for a HA setup.
The default `postgres` chart dependency is not HA-ready (there's a dedicated `postgres-ha` chart).
The following sections discuss each of the components in more detail.
Note that for each component discussed, the shown configurations only provides a (working) starting point, not necessarily the most optimal setup.
We try to optimize this document over time as we have gained more experience with HA setups from users.
## Indexers (Issues and code/repo)
The default code indexer `bleve` is not able to allow multiple connections and hence cannot be used in a HA setup.
Alternatives are `elasticsearch` and `meilisearch` (as of >= 1.19.2).
Unless you have an existing `elasticsearch` cluster, we recommend using `meilisearch` as it is faster and requires way less resources.
Unfortunately, `meilisearch` does only support the `ISSUE_INDEXER` and not the `REPO_INDEXER` yet ([tracking issue](https://github.com/go-gitea/gitea/pull/24149)).
This means that the `REPO_INDEXER` must still be disabled for a HA setup right now.
An alternative to the two options above for the `ISSUE_INDEXER` is `"db"`, however we recommend to just go with `meilisearch` in this case and to not bother the DB with indexing.
To configure `meilisearch` within Gitea, do the following:
Object/asset storage refers to the storage of attachments, avatars, LFS files, etc.
While most of these can be stored on the RWX file-system, it is recommended to use an external S3-compatible object storage for such, mainly for performance reasons.
By default the chart provisions a single RWO volume to store everything (repos, avatars, packages, etc.).
This volume cannot be mounted by multiple pods.
Hence, a RWX volume is required and (optionally) an external HA-ready object storage.
> **Note:** Double-check that the file permissions are set correctly on the RWX volume! That is everything should be owned by the `git` user which usually has `uid=1000` and `gid=1000`.
To use `minio` you need to deploy and configure an external `minio` instance yourself and explicitly define the `STORAGE_TYPE` values as shown below.
Note that `MINIO_BUCKET` here is just a name and does not refer to a S3 bucket.
It's the root access point for all objects belonging to the respective application, i.e., to Gitea in this case.
{{- /*assert that only one PG dep is enabled */ -}}
{{- if and (.Values.postgresql.enabled) (index .Values "postgresql-ha" "enabled") -}}
{{- fail "Only one of postgresql or postgresql-ha can be enabled at the same time." -}}
{{- end }}
{{- /* multiple replicas assertions */ -}}
{{- if gt .Values.replicaCount 1.0 -}}
{{- if (get (get .Values.gitea.config "cron.GIT_GC_REPOS") "ENABLED") -}}
{{- fail "Invoking the garbage collector via CRON is not yet supported when running with multiple replicas. Please set 'cron.GIT_GC_REPOS.enabled = false'." -}}
{{- end }}
{{- if eq (first .Values.persistence.accessModes) "ReadWriteOnce" -}}
{{- fail "When using multiple replicas, a RWX file system is required and gitea.persistence.accessModes[0] must be set to ReadWriteMany." -}}
{{- end }}
{{- if eq (get .Values.gitea.config.indexer "ISSUE_INDEXER_TYPE") "bleve" -}}
{{- fail "When using multiple replicas, the issue indexer (gitea.config.indexer.ISSUE_INDEXER_TYPE) must be set to a HA-ready provider such as 'meilisearch', 'elasticsearch' or 'db' (if the DB is HA-ready)." -}}
{{- end }}
{{- if .Values.gitea.config.indexer.REPO_INDEXER_TYPE -}}
{{- if eq (get .Values.gitea.config.indexer "REPO_INDEXER_TYPE") "bleve" -}}
{{- if .Values.gitea.config.indexer.REPO_INDEXER_ENABLED -}}
{{- if eq (get .Values.gitea.config.indexer "REPO_INDEXER_ENABLED") "true" -}}
{{- fail "When using multiple replicas, the repo indexer (gitea.config.indexer.REPO_INDEXER_TYPE) must be set to 'meilisearch' or 'elasticsearch' or disabled." -}}
{{- end }}
{{- end }}
{{- end }}
{{- end }}
{{- end }}
config_environment.sh:|-
#!/usr/bin/env bash
set -euo pipefail
@ -53,14 +84,14 @@ stringData:
env2ini::log " + '${setting}'"
if [[ -z "${section}" ]]; then
export "ENV_TO_INI____${setting^^}=${value}" # '^^' makes the variable content uppercase
export "GITEA____${setting^^}=${value}" # '^^' makes the variable content uppercase
return
fi
local masked_section="${section//./_0X2E_}" # '//' instructs to replace all matches
masked_section="${masked_section//-/_0X2D_}"
export "ENV_TO_INI__${masked_section^^}__${setting^^}=${value}" # '^^' makes the variable content uppercase
export "GITEA__${masked_section^^}__${setting^^}=${value}" # '^^' makes the variable content uppercase
Some files were not shown because too many files have changed in this diff
Show More
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.
