helm-chart/README.md

1175 lines
57 KiB
Markdown
Raw Normal View History

# Gitea Helm Chart <!-- omit from toc -->
- [Introduction](#introduction)
- [Update and versioning policy](#update-and-versioning-policy)
- [Dependencies](#dependencies)
- [Installing](#installing)
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
- [High Availability](#high-availability)
- [Configuration](#configuration)
- [Default Configuration](#default-configuration)
- [Additional _app.ini_ settings](#additional-appini-settings)
- [External Database](#external-database)
- [Ports and external url](#ports-and-external-url)
- [ClusterIP](#clusterip)
- [SSH and Ingress](#ssh-and-ingress)
- [SSH on crio based kubernetes cluster](#ssh-on-crio-based-kubernetes-cluster)
- [Cache](#cache)
- [Persistence](#persistence)
- [Admin User](#admin-user)
- [LDAP Settings](#ldap-settings)
- [OAuth2 Settings](#oauth2-settings)
- [Configure commit signing](#configure-commit-signing)
- [Metrics and profiling](#metrics-and-profiling)
- [Pod annotations](#pod-annotations)
Document how to add custom themes (#460) <!-- 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>
2023-06-28 01:57:19 -05:00
- [Themes](#themes)
- [Parameters](#parameters)
- [Global](#global)
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
- [strategy](#strategy)
- [Image](#image)
- [Security](#security)
- [Service](#service)
- [Ingress](#ingress)
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
- [deployment](#deployment)
- [ServiceAccount](#serviceaccount)
- [Persistence](#persistence-1)
- [Init](#init)
- [Signing](#signing)
- [Gitea](#gitea)
- [LivenessProbe](#livenessprobe)
- [ReadinessProbe](#readinessprobe)
- [StartupProbe](#startupprobe)
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
- [redis-cluster](#redis-cluster)
- [PostgreSQL-ha](#postgresql-ha)
- [PostgreSQL](#postgresql)
- [Advanced](#advanced)
- [Contributing](#contributing)
- [Upgrading](#upgrading)
[Gitea](https://gitea.io/en-us/) is a community managed lightweight code hosting solution written in Go.
It is published under the MIT license.
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
## Introduction
This helm chart has taken some inspiration from [jfelten's helm chart](https://github.com/jfelten/gitea-helm-chart).
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
Yet it takes a completely different approach in providing a database and cache with dependencies.
Additionally, this chart allows to provide LDAP and admin user configuration with values.
## Update and versioning policy
The Gitea helm chart versioning does not follow Gitea's versioning.
The latest chart version can be looked up in [https://dl.gitea.com/charts](https://dl.gitea.com/charts) or in the [repository releases](https://gitea.com/gitea/helm-chart/releases).
The chart aims to follow Gitea's releases closely.
There might be times when the chart is behind the latest Gitea release.
This might be caused by different reasons, most often due to time constraints of the maintainers (remember, all work here is done voluntarily in the spare time of people).
If you're eager to use the latest Gitea version earlier than this chart catches up, then change the tag in `values.yaml` to the latest Gitea version.
Note that besides the exact Gitea version one can also use the `:1` tag to automatically follow the latest Gitea version.
This should be combined with `image.pullPolicy: "Always"`.
Important: Using the `:1` will also automatically jump to new minor release (e.g. from 1.13 to 1.14) which may eventually cause incompatibilities if major/breaking changes happened between these versions.
This is due to Gitea not strictly following [semantic versioning](https://semver.org/#summary) as breaking changes do not increase the major version.
I.e., "minor" version bumps are considered "major".
Yet most often no issues will be encountered and the chart maintainers aim to communicate early/upfront if this would be the case.
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
## Dependencies
Gitea can be run with an external database and cache.
This chart provides those dependencies, which can be enabled, or disabled via configuration.
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
Dependencies:
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
- PostgreSQL HA ([configuration](#postgresql))
- Redis Cluster ([configuration](#cache))
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
## Installing
```sh
helm repo add gitea-charts https://dl.gitea.io/charts/
helm repo update
helm install gitea gitea-charts/gitea
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
```
When upgrading, please refer to the [Upgrading](#upgrading) section at the bottom of this document for major and breaking changes.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
## High Availability
2023-07-17 14:13:01 -05:00
⚠️ **EXPERIMENTAL** ⚠️
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
Since version 9.0.0 this chart has experimental support for running Gitea and it's dependencies in a HA setup.
The setup is still experimental and care must be taken for production use as Gitea core is not yet officially HA-ready.
Deploying a HA-ready Gitea instance requires some effort including using HA-ready dependencies.
See the [HA Setup](docs/ha-setup.md) document for more details.
## Configuration
Gitea offers lots of configuration options.
This is fully described in the [Gitea Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/).
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
```yaml
gitea:
config:
APP_NAME: "Gitea: With a cup of tea."
repository:
ROOT: "~/gitea-repositories"
repository.pull-request:
WORK_IN_PROGRESS_PREFIXES: "WIP:,[WIP]:"
```
### Default Configuration
This chart will set a few defaults in the Gitea configuration based on the service and ingress settings.
All defaults can be overwritten in `gitea.config`.
INSTALL_LOCK is always set to true, since we want to configure Gitea with this helm chart and everything is taken care of.
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
_All default settings are made directly in the generated `app.ini`, not in the Values._
#### Database defaults
If a builtIn database is enabled the database configuration is set automatically.
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
For example, PostgreSQL builtIn will appear in the `app.ini` as:
```ini
[database]
DB_TYPE = postgres
HOST = RELEASE-NAME-postgresql.default.svc.cluster.local:5432
NAME = gitea
PASSWD = gitea
USER = gitea
```
#### Server defaults
The server defaults are a bit more complex.
If ingress is `enabled`, the `ROOT_URL`, `DOMAIN` and `SSH_DOMAIN` will be set accordingly.
`HTTP_PORT` always defaults to `3000` as well as `SSH_PORT` to `22`.
```ini
[server]
APP_DATA_PATH = /data
DOMAIN = git.example.com
HTTP_PORT = 3000
PROTOCOL = http
ROOT_URL = http://git.example.com
SSH_DOMAIN = git.example.com
SSH_LISTEN_PORT = 22
SSH_PORT = 22
ENABLE_PPROF = false
```
#### Metrics defaults
The Prometheus `/metrics` endpoint is disabled by default.
```ini
[metrics]
ENABLED = false
```
### Additional _app.ini_ settings
> **The [generic](https://docs.gitea.io/en-us/config-cheat-sheet/#overall-default)
> section cannot be defined that way.**
Some settings inside _app.ini_ (like passwords or whole authentication configurations) must be considered sensitive and therefore should not be passed via plain text inside the _values.yaml_ file.
In times of _GitOps_ the values.yaml could be stored in a Git repository where sensitive data should never be accessible.
The Helm Chart supports this approach and let the user define custom sources like
Kubernetes Secrets to be loaded as environment variables during _app.ini_ creation or update.
```yaml
gitea:
additionalConfigSources:
- secret:
secretName: gitea-app-ini-oauth
- configMap:
name: gitea-app-ini-plaintext
```
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
This would mount the two additional volumes (`oauth` and `some-additionals`) from different sources to the init container where the _app.ini_ gets updated.
All files mounted that way will be read and converted to environment variables and then added to the _app.ini_ using [environment-to-ini](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini).
The key of such additional source represents the section inside the _app.ini_.
The value for each key can be multiline ini-like definitions.
In example, the referenced `gitea-app-ini-plaintext` could look like this.
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: gitea-app-ini-plaintext
data:
session: |
PROVIDER=memory
SAME_SITE=strict
cron.archive_cleanup: |
ENABLED=true
```
Or when using a Kubernetes secret, having the same data structure:
```yaml
apiVersion: v1
kind: Secret
metadata:
name: gitea-security-related-configuration
type: Opaque
stringData:
security: |
PASSWORD_COMPLEXITY=off
session: |
SAME_SITE=strict
```
#### User defined environment variables in app.ini
Users are able to define their own environment variables, which are loaded into the containers.
We also support to directly interact with the generated _app.ini_.
To inject self defined variables into the _app.ini_ a certain format needs to be honored.
This is described in detail on the [env-to-ini](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini) page.
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
Prior to Gitea 1.20 and Chart 9.0.0 the helm chart had a custom prefix `ENV_TO_INI`.
After the support for a custom prefix was removed in Gite core, the prefix was changed to `GITEA`.
For example a database setting needs to have the following format:
```yaml
gitea:
additionalConfigFromEnvs:
- name: GITEA__DATABASE__HOST
value: my.own.host
- name: GITEA__DATABASE__PASSWD
valueFrom:
secretKeyRef:
name: postgres-secret
key: password
```
Priority (highest to lowest) for defining app.ini variables:
1. Environment variables prefixed with `GITEA`
1. Additional config sources
1. Values defined in `gitea.config`
### External Database
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
Any external database listed in [https://docs.gitea.io/en-us/database-prep/](https://docs.gitea.io/en-us/database-prep/) can be used instead of the built-in PostgreSQL.
In fact, it is **highly recommended** to use an external database to ensure a stable Gitea installation longterm.
If an external database is used, no matter which type, make sure to set `postgresql.enabled` to `false` to disable the use of the built-in PostgreSQL.
```yaml
gitea:
config:
database:
DB_TYPE: mysql
HOST: <mysql HOST>
NAME: gitea
USER: root
PASSWD: gitea
SCHEMA: gitea
postgresql:
enabled: false
```
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
### Ports and external url
By default port `3000` is used for web traffic and `22` for ssh.
Those can be changed:
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
```yaml
service:
http:
port: 3000
ssh:
port: 22
```
This helm chart automatically configures the clone urls to use the correct ports.
You can change these ports by hand using the `gitea.config` dict.
However you should know what you're doing.
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
### ClusterIP
By default the `clusterIP` will be set to `None`, which is the default for headless services.
However if you want to omit the clusterIP field in the service, use the following values:
```yaml
service:
http:
type: ClusterIP
port: 3000
clusterIP:
ssh:
type: ClusterIP
port: 22
clusterIP:
```
### SSH and Ingress
If you're using ingress and want to use SSH, keep in mind, that ingress is not able to forward SSH Ports.
You will need a LoadBalancer like `metallb` and a setting in your ssh service annotations.
```yaml
service:
ssh:
annotations:
metallb.universe.tf/allow-shared-ip: test
```
### SSH on crio based kubernetes cluster
If you use `crio` as container runtime it is not possible to read from a remote repository.
You should get an error message like this:
```bash
$ git clone git@k8s-demo.internal:admin/test.git
Cloning into 'test'...
Connection reset by 192.168.179.217 port 22
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
```
To solve this problem add the capability `SYS_CHROOT` to the `securityContext`.
More about this issue [here](https://gitea.com/gitea/helm-chart/issues/161).
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
### Cache
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
The cache handling is done via `redis-cluster` (via the `bitnami` chart) by default.
This deployment is HA-ready but can also be used for single-pod deployments.
By default, 6 replicas are deployed for a working `redis-cluster` deployment.
Many cloud providers offer a managed redis service, which can be used instead of the built-in `redis-cluster`.
```yaml
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
redis-cluster:
enabled: true
```
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
### Persistence
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
Gitea will be deployed as a deployment.
By simply enabling the persistence and setting the storage class according to your cluster everything else will be taken care of.
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
The following example will create a PVC as a part of the deployment.
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
Please note, that an empty `storageClass` in the persistence will result in kubernetes using your default storage class.
If you want to use your own storage class define it as follows:
```yaml
persistence:
enabled: true
storageClass: myOwnStorageClass
```
If you want to manage your own PVC you can simply pass the PVC name to the chart.
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
```yaml
persistence:
enabled: true
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
claimName: MyAwesomeGiteaClaim
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
```
In case that persistence has been disabled it will simply use an empty dir volume.
PostgreSQL handles the persistence in the exact same way.
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
You can interact with the postgres settings as displayed in the following example:
```yaml
postgresql:
persistence:
enabled: true
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
claimName: MyAwesomeGiteaPostgresClaim
```
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
### Admin User
This chart enables you to create a default admin user.
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
It is also possible to update the password for this user by upgrading or redeploying the chart.
It is not possible to delete an admin user after it has been created.
This has to be done in the ui.
You cannot use `admin` as username.
```yaml
gitea:
admin:
username: "MyAwesomeGiteaAdmin"
password: "AReallyAwesomeGiteaPassword"
email: "gi@tea.com"
```
You can also use an existing Secret to configure the admin user:
```yaml
apiVersion: v1
kind: Secret
metadata:
name: gitea-admin-secret
type: Opaque
stringData:
username: MyAwesomeGiteaAdmin
password: AReallyAwesomeGiteaPassword
```
```yaml
gitea:
admin:
existingSecret: gitea-admin-secret
```
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
### LDAP Settings
Like the admin user the LDAP settings can be updated.
All LDAP values from <https://docs.gitea.io/en-us/command-line/#admin> are available.
Multiple LDAP sources can be configured with additional LDAP list items.
```yaml
gitea:
ldap:
- name: MyAwesomeGiteaLdap
securityProtocol: unencrypted
host: "127.0.0.1"
port: "389"
userSearchBase: ou=Users,dc=example,dc=com
userFilter: sAMAccountName=%s
adminFilter: CN=Admin,CN=Group,DC=example,DC=com
emailAttribute: mail
bindDn: CN=ldap read,OU=Spezial,DC=example,DC=com
bindPassword: JustAnotherBindPw
usernameAttribute: CN
publicSSHKeyAttribute: publicSSHKey
```
You can also use an existing secret to set the `bindDn` and `bindPassword`:
```yaml
apiVersion: v1
kind: Secret
metadata:
name: gitea-ldap-secret
type: Opaque
stringData:
bindDn: CN=ldap read,OU=Spezial,DC=example,DC=com
bindPassword: JustAnotherBindPw
```
```yaml
gitea:
ldap:
- existingSecret: gitea-ldap-secret
...
```
⚠️ Some options are just flags and therefore don't have any values.
If they are defined in `gitea.ldap` configuration, they will be passed to the Gitea CLI without any value.
Affected options:
- notActive
- skipTlsVerify
- allowDeactivateAll
- synchronizeUsers
- attributesInBind
### OAuth2 Settings
Like the admin user, OAuth2 settings can be updated and disabled but not deleted.
Deleting OAuth2 settings has to be done in the ui.
All OAuth2 values, which are documented [here](https://docs.gitea.io/en-us/command-line/#admin), are
available.
Multiple OAuth2 sources can be configured with additional OAuth list items.
```yaml
gitea:
oauth:
- name: "MyAwesomeGiteaOAuth"
provider: "openidConnect"
key: "hello"
secret: "world"
autoDiscoverUrl: "https://gitea.example.com/.well-known/openid-configuration"
#useCustomUrls:
#customAuthUrl:
#customTokenUrl:
#customProfileUrl:
#customEmailUrl:
```
You can also use an existing secret to set the `key` and `secret`:
```yaml
apiVersion: v1
kind: Secret
metadata:
name: gitea-oauth-secret
type: Opaque
stringData:
key: hello
secret: world
```
```yaml
gitea:
oauth:
- name: "MyAwesomeGiteaOAuth"
existingSecret: gitea-oauth-secret
...
```
## Configure commit signing
When using the rootless image the gpg key folder is not persistent by default.
If you consider using signed commits for internal Gitea activities (e.g. initial commit), you'd need to provide a signing key.
Prior to [PR186](https://gitea.com/gitea/helm-chart/pulls/186), imported keys had to be re-imported once the container got replaced by another.
The mentioned PR introduced a new configuration object `signing` allowing you to configure prerequisites for commit signing.
By default this section is disabled to maintain backwards compatibility.
```yaml
signing:
enabled: false
gpgHome: /data/git/.gnupg
```
Regardless of the used container image the `signing` object allows to specify a private gpg key.
Either using the `signing.privateKey` to define the key inline, or refer to an existing secret containing the key data by using `signing.existingSecret`.
```yaml
apiVersion: v1
kind: Secret
metadata:
name: custom-gitea-gpg-key
type: Opaque
stringData:
privateKey: |-
-----BEGIN PGP PRIVATE KEY BLOCK-----
...
-----END PGP PRIVATE KEY BLOCK-----
```
```yaml
signing:
existingSecret: custom-gitea-gpg-key
```
To use the gpg key, Gitea needs to be configured accordingly.
A detailed description can be found in the [official Gitea documentation](https://docs.gitea.io/en-us/signing/#general-configuration).
## Metrics and profiling
A Prometheus `/metrics` endpoint on the `HTTP_PORT` and `pprof` profiling endpoints on port 6060 can be enabled under `gitea`.
Beware that the metrics endpoint is exposed via the ingress, manage access using ingress annotations for example.
To deploy the `ServiceMonitor`, you first need to ensure that you have deployed `prometheus-operator` and its [CRDs](https://github.com/prometheus-operator/prometheus-operator#customresourcedefinitions).
```yaml
gitea:
metrics:
enabled: true
serviceMonitor:
enabled: true
config:
server:
ENABLE_PPROF: true
```
## Pod annotations
Annotations can be added to the Gitea pod.
```yaml
gitea:
podAnnotations: {}
```
Document how to add custom themes (#460) <!-- 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>
2023-06-28 01:57:19 -05:00
## Themes
Custom themes can be added via k8s secrets and referencing them in `values.yaml`.
```yaml
extraVolumes:
- name: gitea-themes
secret:
secretName: gitea-themes
extraVolumeMounts:
- name: gitea-themes
readOnly: true
mountPath: "/data/gitea/public/css"
```
The secret can be created via `terraform`:
```hcl
resource "kubernetes_secret" "gitea-themes" {
metadata {
name = "gitea-themes"
namespace = "gitea"
}
data = {
"theme-custom.css" = "${file("FULL-PATH-TO-CSS")}"
"theme-custom-dark.css" = "${file("FULL-PATH-TO-CSS")}"
}
type = "Opaque"
depends_on = [kubernetes_namespace.gitea]
}
```
or natively via `kubectl`:
```bash
kubectl create secret generic gitea-themes --from-file={{FULL-PATH-TO-CSS}} --namespace gitea
```
## Parameters
### Global
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
| Name | Description | Value |
| ------------------------- | ------------------------------------------------------------------------- | ----- |
| `global.imageRegistry` | global image registry override | `""` |
| `global.imagePullSecrets` | global image pull secrets override; can be extended by `imagePullSecrets` | `[]` |
| `global.storageClass` | global storage class override | `""` |
| `global.hostAliases` | global hostAliases which will be added to the pod's hosts files | `[]` |
| `replicaCount` | number of replicas for the deployment | `1` |
### strategy
| Name | Description | Value |
| --------------------------------------- | -------------- | --------------- |
| `strategy.type` | strategy type | `RollingUpdate` |
| `strategy.rollingUpdate.maxSurge` | maxSurge | `100%` |
| `strategy.rollingUpdate.maxUnavailable` | maxUnavailable | `0` |
| `clusterDomain` | cluster domain | `cluster.local` |
### Image
| Name | Description | Value |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | ------------- |
| `image.registry` | image registry, e.g. gcr.io,docker.io | `""` |
| `image.repository` | Image to start for this pod | `gitea/gitea` |
| `image.tag` | Visit: [Image tag](https://hub.docker.com/r/gitea/gitea/tags?page=1&ordering=last_updated). Defaults to `appVersion` within Chart.yaml. | `""` |
| `image.pullPolicy` | Image pull policy | `Always` |
| `image.rootless` | Wether or not to pull the rootless version of Gitea, only works on Gitea 1.14.x or higher | `true` |
| `imagePullSecrets` | Secret to use for pulling the image | `[]` |
### Security
| Name | Description | Value |
| ---------------------------- | --------------------------------------------------------------- | ------ |
| `podSecurityContext.fsGroup` | Set the shared file system group for all containers in the pod. | `1000` |
| `containerSecurityContext` | Security context | `{}` |
| `securityContext` | Run init and Gitea containers as a specific securityContext | `{}` |
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
| `podDisruptionBudget` | Pod disruption budget | `{}` |
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
### Service
| Name | Description | Value |
| --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
| `service.http.type` | Kubernetes service type for web traffic | `ClusterIP` |
| `service.http.port` | Port number for web traffic | `3000` |
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
| `service.http.clusterIP` | ClusterIP setting for http autosetup for deployment is None | `None` |
| `service.http.loadBalancerIP` | LoadBalancer IP setting | `nil` |
| `service.http.nodePort` | NodePort for http service | `nil` |
| `service.http.externalTrafficPolicy` | If `service.http.type` is `NodePort` or `LoadBalancer`, set this to `Local` to enable source IP preservation | `nil` |
| `service.http.externalIPs` | External IPs for service | `nil` |
| `service.http.ipFamilyPolicy` | HTTP service dual-stack policy | `nil` |
| `service.http.ipFamilies` | HTTP service dual-stack familiy selection,for dual-stack parameters see official kubernetes [dual-stack concept documentation](https://kubernetes.io/docs/concepts/services-networking/dual-stack/). | `nil` |
| `service.http.loadBalancerSourceRanges` | Source range filter for http loadbalancer | `[]` |
| `service.http.annotations` | HTTP service annotations | `{}` |
| `service.ssh.type` | Kubernetes service type for ssh traffic | `ClusterIP` |
| `service.ssh.port` | Port number for ssh traffic | `22` |
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
| `service.ssh.clusterIP` | ClusterIP setting for ssh autosetup for deployment is None | `None` |
| `service.ssh.loadBalancerIP` | LoadBalancer IP setting | `nil` |
| `service.ssh.nodePort` | NodePort for ssh service | `nil` |
| `service.ssh.externalTrafficPolicy` | If `service.ssh.type` is `NodePort` or `LoadBalancer`, set this to `Local` to enable source IP preservation | `nil` |
| `service.ssh.externalIPs` | External IPs for service | `nil` |
| `service.ssh.ipFamilyPolicy` | SSH service dual-stack policy | `nil` |
| `service.ssh.ipFamilies` | SSH service dual-stack familiy selection,for dual-stack parameters see official kubernetes [dual-stack concept documentation](https://kubernetes.io/docs/concepts/services-networking/dual-stack/). | `nil` |
| `service.ssh.hostPort` | HostPort for ssh service | `nil` |
| `service.ssh.loadBalancerSourceRanges` | Source range filter for ssh loadbalancer | `[]` |
| `service.ssh.annotations` | SSH service annotations | `{}` |
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
### Ingress
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
| Name | Description | Value |
| ------------------------------------ | --------------------------------------------------------------------------- | ----------------- |
| `ingress.enabled` | Enable ingress | `false` |
| `ingress.className` | Ingress class name | `nil` |
| `ingress.annotations` | Ingress annotations | `{}` |
| `ingress.hosts[0].host` | Default Ingress host | `git.example.com` |
| `ingress.hosts[0].paths[0].path` | Default Ingress path | `/` |
| `ingress.hosts[0].paths[0].pathType` | Ingress path type | `Prefix` |
| `ingress.tls` | Ingress tls settings | `[]` |
| `ingress.apiVersion` | Specify APIVersion of ingress object. Mostly would only be used for argocd. | |
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
### deployment
| Name | Description | Value |
| ------------------------------------------ | ------------------------------------------------------ | ----- |
| `resources` | Kubernetes resources | `{}` |
| `schedulerName` | Use an alternate scheduler, e.g. "stork" | `""` |
| `nodeSelector` | NodeSelector for the deployment | `{}` |
| `tolerations` | Tolerations for the deployment | `[]` |
| `affinity` | Affinity for the deployment | `{}` |
| `topologySpreadConstraints` | TopologySpreadConstraints for the deployment | `[]` |
| `dnsConfig` | dnsConfig for the deployment | `{}` |
| `priorityClassName` | priorityClassName for the deployment | `""` |
| `deployment.env` | Additional environment variables to pass to containers | `[]` |
| `deployment.terminationGracePeriodSeconds` | How long to wait until forcefully kill the pod | `60` |
| `deployment.labels` | Labels for the deployment | `{}` |
| `deployment.annotations` | Annotations for the Gitea deployment to be created | `{}` |
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 12:56:55 -05:00
### ServiceAccount
| Name | Description | Value |
| --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| `serviceAccount.create` | Enable the creation of a ServiceAccount | `false` |
| `serviceAccount.name` | Name of the created ServiceAccount, defaults to release name. Can also link to an externally provided ServiceAccount that should be used. | `""` |
| `serviceAccount.automountServiceAccountToken` | Enable/disable auto mounting of the service account token | `false` |
| `serviceAccount.imagePullSecrets` | Image pull secrets, available to the ServiceAccount | `[]` |
| `serviceAccount.annotations` | Custom annotations for the ServiceAccount | `{}` |
| `serviceAccount.labels` | Custom labels for the ServiceAccount | `{}` |
### Persistence
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
| Name | Description | Value |
| ---------------------------- | ----------------------------------------------------------------------------------------------------- | ---------------------- |
| `persistence.enabled` | Enable persistent storage | `true` |
| `persistence.create` | Whether to create the persistentVolumeClaim for shared storage | `true` |
| `persistence.mount` | Whether the persistentVolumeClaim should be mounted (even if not created) | `true` |
| `persistence.claimName` | Use an existing claim to store repository information | `gitea-shared-storage` |
| `persistence.size` | Size for persistence to store repo information | `10Gi` |
| `persistence.accessModes` | AccessMode for persistence | `["ReadWriteOnce"]` |
| `persistence.labels` | Labels for the persistence volume claim to be created | `{}` |
| `persistence.annotations` | Annotations for the persistence volume claim to be created | `{}` |
| `persistence.storageClass` | Name of the storage class to use | `nil` |
| `persistence.subPath` | Subdirectory of the volume to mount at | `nil` |
| `extraVolumes` | Additional volumes to mount to the Gitea deployment | `[]` |
| `extraContainerVolumeMounts` | Mounts that are only mapped into the Gitea runtime/main container, to e.g. override custom templates. | `[]` |
| `extraInitVolumeMounts` | Mounts that are only mapped into the init-containers. Can be used for additional preconfiguration. | `[]` |
| `extraVolumeMounts` | **DEPRECATED** Additional volume mounts for init containers and the Gitea main container | `[]` |
### Init
| Name | Description | Value |
| ------------------------------------------ | ------------------------------------------------------------------------------------ | ------- |
| `initPreScript` | Bash shell script copied verbatim to the start of the init-container. | `""` |
| `initContainers.resources.limits` | initContainers.limits Kubernetes resource limits for init containers | `{}` |
| `initContainers.resources.requests.cpu` | initContainers.requests.cpu Kubernetes cpu resource limits for init containers | `100m` |
| `initContainers.resources.requests.memory` | initContainers.requests.memory Kubernetes memory resource limits for init containers | `128Mi` |
### Signing
| Name | Description | Value |
| ------------------------ | ----------------------------------------------------------------- | ------------------ |
| `signing.enabled` | Enable commit/action signing | `false` |
| `signing.gpgHome` | GPG home directory | `/data/git/.gnupg` |
| `signing.privateKey` | Inline private gpg key for signed Gitea actions | `""` |
| `signing.existingSecret` | Use an existing secret to store the value of `signing.privateKey` | `""` |
### Gitea
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
| Name | Description | Value |
| -------------------------------------- | ------------------------------------------------------------------------- | -------------------- |
| `gitea.admin.username` | Username for the Gitea admin user | `gitea_admin` |
| `gitea.admin.existingSecret` | Use an existing secret to store admin user credentials | `nil` |
| `gitea.admin.password` | Password for the Gitea admin user | `r8sA8CPHD9!bt6d` |
| `gitea.admin.email` | Email for the Gitea admin user | `gitea@local.domain` |
| `gitea.metrics.enabled` | Enable Gitea metrics | `false` |
| `gitea.metrics.serviceMonitor.enabled` | Enable Gitea metrics service monitor | `false` |
| `gitea.ldap` | LDAP configuration | `[]` |
| `gitea.oauth` | OAuth configuration | `[]` |
| `gitea.config.server.SSH_PORT` | SSH port for rootlful Gitea image | `22` |
| `gitea.config.server.SSH_LISTEN_PORT` | SSH port for rootless Gitea image | `2222` |
| `gitea.additionalConfigSources` | Additional configuration from secret or configmap | `[]` |
| `gitea.additionalConfigFromEnvs` | Additional configuration sources from environment variables | `[]` |
| `gitea.podAnnotations` | Annotations for the Gitea pod | `{}` |
| `gitea.ssh.logLevel` | Configure OpenSSH's log level. Only available for root-based Gitea image. | `INFO` |
### LivenessProbe
| Name | Description | Value |
| ----------------------------------------- | ------------------------------------------------ | ------ |
| `gitea.livenessProbe.enabled` | Enable liveness probe | `true` |
| `gitea.livenessProbe.tcpSocket.port` | Port to probe for liveness | `http` |
| `gitea.livenessProbe.initialDelaySeconds` | Initial delay before liveness probe is initiated | `200` |
| `gitea.livenessProbe.timeoutSeconds` | Timeout for liveness probe | `1` |
| `gitea.livenessProbe.periodSeconds` | Period for liveness probe | `10` |
| `gitea.livenessProbe.successThreshold` | Success threshold for liveness probe | `1` |
| `gitea.livenessProbe.failureThreshold` | Failure threshold for liveness probe | `10` |
### ReadinessProbe
| Name | Description | Value |
| ------------------------------------------ | ------------------------------------------------- | ------ |
| `gitea.readinessProbe.enabled` | Enable readiness probe | `true` |
| `gitea.readinessProbe.tcpSocket.port` | Port to probe for readiness | `http` |
| `gitea.readinessProbe.initialDelaySeconds` | Initial delay before readiness probe is initiated | `5` |
| `gitea.readinessProbe.timeoutSeconds` | Timeout for readiness probe | `1` |
| `gitea.readinessProbe.periodSeconds` | Period for readiness probe | `10` |
| `gitea.readinessProbe.successThreshold` | Success threshold for readiness probe | `1` |
| `gitea.readinessProbe.failureThreshold` | Failure threshold for readiness probe | `3` |
### StartupProbe
| Name | Description | Value |
| ---------------------------------------- | ----------------------------------------------- | ------- |
| `gitea.startupProbe.enabled` | Enable startup probe | `false` |
| `gitea.startupProbe.tcpSocket.port` | Port to probe for startup | `http` |
| `gitea.startupProbe.initialDelaySeconds` | Initial delay before startup probe is initiated | `60` |
| `gitea.startupProbe.timeoutSeconds` | Timeout for startup probe | `1` |
| `gitea.startupProbe.periodSeconds` | Period for startup probe | `10` |
| `gitea.startupProbe.successThreshold` | Success threshold for startup probe | `1` |
| `gitea.startupProbe.failureThreshold` | Failure threshold for startup probe | `10` |
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
### redis-cluster
| Name | Description | Value |
| ------------------------------------- | ---------------------------------------------------- | ------- |
| `redis-cluster.enabled` | Enable redis | `true` |
| `redis-cluster.global.redis.password` | Password for the "Gitea" user (overrides `password`) | `gitea` |
### PostgreSQL-ha
| Name | Description | Value |
| -------------------------------------------------- | ---------------------------------------------------------------- | ---------- |
| `postgresql-ha.enabled` | Enable PostgreSQL-ha | `true` |
| `postgresql-ha.global.postgresql.password` | Password for the `gitea` user (overrides `auth.password`) | `gitea` |
| `postgresql-ha.global.postgresql.database` | Name for a custom database to create (overrides `auth.database`) | `gitea` |
| `postgresql-ha.global.postgresql.username` | Name for a custom user to create (overrides `auth.username`) | `gitea` |
| `postgresql-ha.global.postgresql.postgresPassword` | Postgres Password | `changeme` |
| `postgresql-ha.global.postgresql.repmgrPassword` | Repmgr Password | `changeme` |
| `postgresql-ha.service.ports.postgresql` | PostgreSQL service port (overrides `service.ports.postgresql`) | `5432` |
| `postgresql-ha.primary.persistence.size` | PVC Storage Request for PostgreSQL-ha volume | `10Gi` |
### PostgreSQL
| Name | Description | Value |
| ------------------------------------------------------- | ---------------------------------------------------------------- | ------- |
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
| `postgresql.enabled` | Enable PostgreSQL | `false` |
add `extraDeploy` to add arbitrary objects to the release (#441) 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>
2023-05-02 08:32:54 -05:00
| `postgresql.global.postgresql.auth.password` | Password for the `gitea` user (overrides `auth.password`) | `gitea` |
| `postgresql.global.postgresql.auth.database` | Name for a custom database to create (overrides `auth.database`) | `gitea` |
| `postgresql.global.postgresql.auth.username` | Name for a custom user to create (overrides `auth.username`) | `gitea` |
| `postgresql.global.postgresql.service.ports.postgresql` | PostgreSQL service port (overrides `service.ports.postgresql`) | `5432` |
| `postgresql.primary.persistence.size` | PVC Storage Request for PostgreSQL volume | `10Gi` |
### Advanced
| Name | Description | Value |
| ------------------ | ------------------------------------------------------------------ | --------- |
| `checkDeprecation` | Set it to false to skip this basic validation check. | `true` |
| `test.enabled` | Set it to false to disable test-connection Pod. | `true` |
| `test.image.name` | Image name for the wget container used in the test-connection Pod. | `busybox` |
| `test.image.tag` | Image tag for the wget container used in the test-connection Pod. | `latest` |
add `extraDeploy` to add arbitrary objects to the release (#441) 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>
2023-05-02 08:32:54 -05:00
| `extraDeploy` | Array of extra objects to deploy with the release | `[]` |
## Contributing
Expected workflow is: Fork -> Patch -> Push -> Pull Request
See [CONTRIBUTORS GUIDE](CONTRIBUTING.md) for details.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
## Upgrading
This section lists major and breaking changes of each Helm Chart version.
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
Please read them carefully to upgrade successfully, especially the change of the **default database backend**!
If you miss this, blindly upgrading may delete your Postgres instance and you may lose your data!
<details>
<summary>To 9.0.0</summary>
This chart release comes with many breaking changes while aiming for a HA-ready setup.
Please go through all of them carefully to perform a successful upgrade.
Here's a brief summary again, followed by more detailed migration instructions:
- Switch from `Statefulset` to `Deployment`
- Switch from `Memcached` to `redis-cluster` as the default session and queue provider
- Switch from `postgres` to `postgres-ha` as the default database provider
- A chart-internal PVC bootstrapping logic
- New `persistence.mount`: whether to mount an existent PVC (even if not creating it)
- New `persistence.create`: whether to create a new PVC
- Renamed `persistence.existingClaim` to `persistence.claimName`
While not required, we recommend to start with a RWX PV for new installations.
A RWX volume is required for installation aiming for HA.
If you want to stay with a pre-existing RWO PV, you need to set
- `persistence.mount=true`
- `persistence.create=false`
- `persistence.claimName` to the name of your existing PVC.
If you do not, Gitea will create a new PVC which will in turn create a new PV.
If this happened to you by accident, you can still recover your data by setting using the settings from above in a subsequent run.
If you want to stay with a `memcache` instead of `redis-cluster`, you need to deploy `memcache` manually (e.g. from [bitnami](https://github.com/bitnami/charts/tree/main/bitnami/memcached)) and set
- `cache.HOST = "<memcache connection string>"`
- `cache.ADAPTER = "memcache"`
- `session.PROVIDER = "memcache"`
- `session.PROVIDER_CONFIG = "<memcache connection string>"`
- `queue.TYPE = "memcache"`
- `queue.CONN_STR = "<memcache connection string>"`
The `memcache` connection string has the scheme `memcache://<memcache service name>:<memcache service port>`, e.g. `gitea-memcached.gitea.svc.cluster.local:11211`.
The first item here (`<memcache service name>`) will be different compared to the example if you deploy `memcache` yourself.
The above changes are motivated by the idea to tidy dependencies but also have HA-ready ones at the same time.
The previous `memcache` default was not HA-ready, hence we decided to switch to `redis-cluster` by default.
If you are coming from an existing deployment and [#356](https://gitea.com/gitea/helm-chart/issues/356) is still open, you need to set the config sections for `cache`, `session` and `queue` explicitly:
```yaml
session:
2023-07-19 02:57:44 -05:00
PROVIDER: redis-cluster
PROVIDER_CONFIG: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&
cache:
ENABLED: true
2023-07-19 02:57:44 -05:00
ADAPTER: redis-cluster
HOST: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&
queue:
TYPE: redis
CONN_STR: redis+cluster://:gitea@gitea-redis-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&
```
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
<!-- markdownlint-disable-next-line -->
**Transitioning from a RWO to RWX Persistent Volume**
If you want to switch to a RWX volume and go for HA, you need to
1. Backup the data stored under `/data`
2. Let the chart create a new RWX PV (or do it statically yourself)
3. Restore the backup to the same location in the new PV
<!-- markdownlint-disable-next-line -->
**Transitioning from Postgres to Postgres HA**
If you are running with a non-HA PG DB from a previous chart release, you need to set
- `postgresql-ha.enabled=false`
- `postgresql.enabled=true`
This is needed to stay with your existing single-instance DB (as the HA-variant is the new default).
<!-- markdownlint-disable-next-line -->
**Change of env-to-ini prefix**
Before this release, the env-to-ini prefix was `ENV_TO_INI__`.
This allowed a clear distinction between user-provided and chart-provided env-to-ini variables.
Due to the removal custom prefix feature in the upstream implementation of env-to-ini, the prefix has been changed to the default `GITEA__`.
If you previously had defined env vars that had the `ENV_TO_INI__` prefix, you need to change them to `GITEA__` in order for them to be picked up by the chart.
[Breaking] Add HA-support; switch to `Deployment` (#437) # 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>
2023-07-17 14:09:42 -05:00
</details>
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
<details>
<summary>To 8.0.0</summary>
### Removal of MariaDB and MySQL DB chart dependencies <!-- omit from toc -->
In this version support for DB chart dependencies of MySQL and MariaDB have been removed to simplify the maintenance of the helm chart.
External MySQL and MariaDB databases are still supported and will be in the future.
### Postgres Update from v11 to v15 <!-- omit from toc -->
This Chart version updates the Postgres chart dependency and subsequently Postgres from v11 to v15.
Please read the [Postgres Release Notes](https://www.postgresql.org/docs/release/) for version-specific changes.
With respect to `values.yaml`, parameters `username`, `database` and `password` have been regrouped under `auth` and slightly renamed.
`persistence` has also been regrouped under the `primary` key.
Please adjust your `values.yaml` accordingly.
**Attention**: The Postgres upgrade is not automatically handled by the chart and must be done by yourself.
See [this comment](https://gitea.com/gitea/helm-chart/issues/452#issuecomment-740885) for an extensive walkthrough.
We again highly encourage users to use an external (managed) database for production instances.
</details>
<details>
<summary>To 7.0.0</summary>
### Private GPG key configuration for Gitea signing actions <!-- omit from toc -->
Having `signing.enabled=true` now requires to use either `signing.privateKey` or `signing.existingSecret` so that the Chart can automatically prepare the GPG key for Gitea internal signing actions.
See [Configure commit signing](#configure-commit-signing) for details.
</details>
<details>
<summary>To 6.0.0</summary>
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
### Different volume mounts for init-containers and runtime container <!-- omit from toc -->
**The `extraVolumeMounts` is deprecated** in favor of `extraInitVolumeMounts` and `extraContainerVolumeMounts`.
You can now have different mounts for the initialization phase and Gitea runtime.
The deprecated `extraVolumeMounts` will still be available for the time being and is mounted into every container.
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.
**Combining values from the deprecated setting with values from the new settings is not possible.**
### New `enabled` flag for `startupProbe` <!-- omit from toc -->
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
Prior to this version the `startupProbe` was just a commented sample within the `values.yaml`.
With the migration to an auto-generated [Parameters](#parameters) section, a new parameter `gitea.startupProbe.enabled` has been introduced set to
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
`false` by default.
If you are using the `startupProbe` you need to add that new parameter and set it to `true`.
Otherwise, your defined probe won't be considered after the upgrade.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
</details>
<details>
<summary>To 5.0.0</summary>
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
> 💥 The Helm Chart now requires Gitea versions of at least 1.11.0.
### Enable Dependencies <!-- omit from toc -->
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
The values to enable the dependencies, such as PostgreSQL, Memcached, MySQL and MariaDB have been moved from `gitea.database.builtIn.` to the dependency values.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
You can now enable the dependencies as followed:
```yaml
memcached:
enabled: true
postgresql:
enabled: true
mysql:
enabled: false
mariadb:
enabled: false
```
### App.ini generation <!-- omit from toc -->
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
The app.ini generation has changed and now utilizes the environment-to-ini script provided by newer Gitea versions.
This change ensures, that the app.ini is now persistent.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
### Secret Key generation <!-- omit from toc -->
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
Gitea secret keys (SECRET_KEY, INTERNAL_TOKEN, JWT_SECRET) are now generated automatically in certain situations:
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
- New install: By default the secrets are created automatically.
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 configuration nor via auto generation.
We explicitly prevent to set new secrets.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
> 💡 It would be possible to set new secret keys manually by entering the running container and rewriting the app.ini by hand.
> However, this it is not advisable to do so for existing installations.
> Certain settings like _LDAP_ would not be readable anymore.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
### Probes <!-- omit from toc -->
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
`gitea.customLivenessProbe`, `gitea.customReadinessProbe` and `gitea.customStartupProbe` have been removed.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
They are replaced by the settings `gitea.livenessProbe`, `gitea.readinessProbe` and `gitea.startupProbe` which are now fully configurable and used _as-is_ for
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
a Chart deployment.
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.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
In case you want to disable one of these probes, let's say the `livenessProbe`, add the following to your values.
The `podAnnotation` is just there to have a bit more context.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
```diff
gitea:
+ livenessProbe:
podAnnotations: {}
```
### Multiple OAuth and LDAP authentication sources <!-- omit from toc -->
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
With `5.0.0` of this Chart it is now possible to configure Gitea with multiple OAuth and LDAP sources.
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
of settings objects.
See [OAuth2 Settings](#oauth2-settings) and [LDAP Settings](#ldap-settings) section for details.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
</details>
<details>
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
<summary>To 4.0.0</summary>
### Ingress changes <!-- omit from toc -->
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
To provide a more flexible Ingress configuration we now support not only host settings but also provide configuration for the path and pathType.
So this change changes the hosts from a simple string list, to a list containing a more complex object for more configuration.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
```diff
ingress:
enabled: false
annotations: {}
# kubernetes.io/ingress.class: nginx
# kubernetes.io/tls-acme: "true"
- hosts:
- - git.example.com
+ hosts:
+ - host: git.example.com
+ paths:
+ - path: /
+ pathType: Prefix
tls: []
# - secretName: chart-example-tls
# hosts:
# - git.example.com
```
If you want everything as it was before, you can simply add the following code to all your host entries.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
```yaml
paths:
- path: /
pathType: Prefix
```
### Dropped kebab-case support <!-- omit from toc -->
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
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.
See [LDAP section](#ldap-settings) for more information.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
### Dependency update <!-- omit from toc -->
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
The chart comes with multiple databases and Memcached as dependency, the latest release updated the dependencies.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
- Memcached: `4.2.20` -> `5.9.0`
- PostgreSQL: `9.7.2` -> `10.3.17`
- MariaDB: `8.0.0` -> `9.3.6`
If you're using the builtin databases you will most likely redeploy the chart in order to update the database correctly.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
### Execution of initPreScript <!-- omit from toc -->
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
Generally spoken, this might not be a breaking change, but it is worth to be mentioned.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
Prior to `4.0.0` only one init container was used to both setup directories and configure Gitea.
As of now the actual Gitea configuration is separated from the other pre-execution.
This also includes the execution of _initPreScript_.
If you have such script, please be aware of this.
Dynamically prepare the Gitea setup during execution by e.g. adding environment variables to the execution context won't work anymore.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
### Gitea Version 1.14.X repository ROOT <!-- omit from toc -->
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
Previously the ROOT folder for the Gitea repositories was located at `/data/git/gitea-repositories`.
In version `1.14` has the path been changed to `/data/gitea-repositories`.
Restructure changelog/upgrading approach (#331) 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>
2022-07-15 12:27:48 -05:00
This chart will set the `gitea.config.repository.ROOT` value default to `/data/git/gitea-repositories`.
</details>