6 Commits

Include renames

Author	SHA1	Message	Date
volker.raschekandCopilot	3c9fc19829	feat(deployment)!: move image to deployment.gitea.image ... The `image` values only ever configured the Gitea container itself — registry, repository, tag, digest, pull policy and the rootless variant are all consumed by the `gitea` container and its init containers. Keeping them at the top level suggested a chart-wide scope that never existed and separated them from the other container-scoped settings that already live under `deployment.gitea` (`env`, `resources`). Moving the block makes the container configuration self-contained and continues the consolidation of all pod- and Deployment-scoped values under the `deployment` dict. `imagePullSecrets` intentionally stays top-level, because it is a pod-level setting that also applies to `extraContainers` and is paired with `global.imagePullSecrets`. BREAKING CHANGE: `image` no longer exists. Use `deployment.gitea.image` instead. Values still set under `image` are silently ignored, which would drop a pinned `tag` or `digest` and roll out the chart default (`appVersion`) instead — review your values before upgrading. Co-authored-by: Copilot <copilot@github.com>	2026-09-04 13:07:47 +02:00
volker.raschekandCopilot	f385d22b56	feat(deployment)!: move replicaCount to deployment.replicas ... The top-level `replicaCount` value only ever set the replica count of the Gitea Deployment, but was declared next to chart-wide settings. Moving it into the `deployment` dict completes the consolidation already done for `affinity`, `dnsConfig`, `nodeSelector`, `priorityClassName`, `resources`, `schedulerName`, `strategy`, `tolerations` and `topologySpreadConstraints`. The key was renamed from `replicaCount` to `replicas` at the same time. Every other key inside the `deployment` dict mirrors the name of the corresponding Kubernetes field, so `deployment.replicas` maps one to one onto `spec.replicas` and removes the need to remember a chart-specific alias. A deprecation check fails the release when the removed top-level value is still set. Silently ignoring it would be severe here: the release would scale back down to a single replica without any warning, and the HA guards in the PVC and config templates, which key off the replica count, would no longer apply. BREAKING CHANGE: `replicaCount` no longer exists. Use `deployment.replicas` instead. Installations that still set `replicaCount` will fail unless `checkDeprecation` is set to `false`. Co-authored-by: Copilot <copilot@github.com>	2026-09-04 12:16:54 +02:00
Sean Teoandpat-s	6e4e414771	chore(deps)!: Migrate to Valkey from Redis (#775) ... <!-- 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 Migrates from Redis to Valkey. ### Benefits The Redis License is changing from BSD-3-Clause to RSALv2 and SSPLv1 which are not open source under the OSI definition. We should consider open-source alternatives as a default replacement for Redis. ### Possible drawbacks Large scale change, potentially breaking. ### Applicable issues https://github.com/go-gitea/gitea/issues/32056 ### ⚠ BREAKING Major version change, redis provider changed to valkey. ### 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] Helm templating unittests are added (required when changing anything in `templates` folder) Co-authored-by: pat-s <patrick.schratz@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/775 Reviewed-by: pat-s <pat-s@noreply.gitea.com> Co-authored-by: Sean Teo <sawntoe@gmail.com> Co-committed-by: Sean Teo <sawntoe@gmail.com>	2025-05-05 08:12:41 +00:00
pat-s	7eea1acf05	chore: reduce redis-cluster pods and move HA out of "experimental" state (#565) ... The pod reduction for `redis-cluster` should help users seeking for a Gitea deployment with less pods. Users seeking for a minimal deployment are further advised to follow https://gitea.com/gitea/helm-chart#user-content-single-pod-configurations. HA is working fine in the provided configuration and should be moved out of the "experimental" state given that there were no reports of Gitea malfunctioning reported to HA usage in recent months/since v9 release. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/565 Reviewed-by: techknowlogick <techknowlogick@noreply.gitea.com> Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>	2023-11-16 10:14:34 +00:00
pat-s	950e46ce44	add experimental note	2023-07-17 21:13:01 +02:00
pat-sandpat-s	8e27bb9bae	[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 19:09:42 +00:00