### Benefits
Can protect metrics endpoint with `Bearer` token authentication provided by gitea.
see PR #637 for previous discussion.
### Possible drawbacks
No possible drawbacks
### Applicable issues
- fixes#635
### Additional information
```
gitea:
metrics:
enabled: true
token: "somepassword"
serviceMonitor:
enabled: true
```
Using above configuration is sufficient to secure /metrics endpoint with bearer token and corresponding ServiceMonitor.
### Checklist
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [ ] ~~Breaking changes are documented in the `README.md`~~ Not applicable
- [x] Templating unittests are added
Signed-off-by: Hitesh Nayak <hiteshnayak305@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/719
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: Hitesh Nayak <hiteshnayak305@gmail.com>
Co-committed-by: Hitesh Nayak <hiteshnayak305@gmail.com>
### Description of the change
Adds an 'extraContainers' parameter.
### Benefits
Users will be able to run sidecar containers as required by their environment.
### Possible drawbacks
N/A
### Applicable issues
- Fixes#696
### Checklist
- [X] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/697
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: rossigee <rossigee@noreply.gitea.com>
Co-committed-by: rossigee <rossigee@noreply.gitea.com>
### Description of the change
Added namespaces to all the template files to better support alternate templaters in gitops systems
### Benefits
Gitops system that have different ways of handling helm templates can actually deploy this chart correct, especially through subcharts
### Possible drawbacks
Potential regression when upgrading, though this should be unlikely per @jessesanford 's comments with it defaulting back to the existing behaviour
### Applicable issues
- Addresses https://gitea.com/gitea/helm-chart/issues/630
- Addresses https://gitea.com/gitea/helm-chart/issues/557
- Addresses https://gitea.com/gitea/helm-chart/issues/623
### Checklist
- [X] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [X] Breaking changes are documented in the `README.md`
Co-authored-by: SorsOps <80043879+sorsOps@users.noreply.github.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/713
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: SorsOps <sorsops@noreply.gitea.com>
Co-committed-by: SorsOps <sorsops@noreply.gitea.com>
This patch extends the serviceMonitor resource to specify a custom TLS
configuration used by prometheus to scrape the metrics.
Furthermore, the interval and scrapeTimeout can now be adapted without changing
the global defaults of the prometheus instance.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/710
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Markus Pesch <markus.pesch@cryptic.systems>
Co-committed-by: Markus Pesch <markus.pesch@cryptic.systems>
### Description of the change
Introduce `service.{http,ssh}.loadBalancerClass`
### Benefits
Feature was not supported before. This is required if your cluster has multiple loadBalancer options and you want to select one
### Possible drawbacks
More yaml.
### Checklist
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [x] Templating unittests are added
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/640
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: Karitham <kar@karitham.dev>
Co-committed-by: Karitham <kar@karitham.dev>
### Description of the change
This enables sane modes for forcing reset, as well as providing more options to users of the chart by giving them the flexibility to set the mode for password creation/modification as part of init whether the user exists or not.
### Benefits
The new default should revert to the behavior before #673 became an issue, while also providing more flexibility for users who want to be able to manage their initial admin user password out-of-band after creating it the first time.
### Possible drawbacks
None that I can think of.
### Applicable issues
- fixes#673
### Additional information
See the discussion in #675 as well
### Checklist
- [X] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/677
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: James Harmison <jharmison@gmail.com>
Co-committed-by: James Harmison <jharmison@gmail.com>
The current README content is a result of running markdownlint with simple fixes enabled.
It shouldn't fix _any_ issues, even after generating the parameter section.
Unfortunately, this is not the case right now.
This resolves the long-running dispute of both tools. 😉
---
Since I already modified the `values.yaml`, I decided to include a change regarding code signing.
Otherwise, it may confuse users after merging #596.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/627
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
### Description of the change
The change allows users of this chart to specify custom labels for the HTTP & SSH Services that get deployed. They are optional and if given are added to the standard list of labels.
### Benefits
Certain use cases require labelling services to be able to select them in other places. Specifiying them directly in the helm chart avoids having to label by hand everytime.
Concrete Use Case Example: Cilium Layer 2 Announcements require selecting services to announce via labels (see [docs](https://docs.cilium.io/en/stable/network/l2-announcements/#service-selector)). I would like to add a label to the SSH service, but not the HTTP Service (which is handled via an ingress).
### Possible drawbacks
I don't see any, using this feature is optional :)
### Checklist
- [X] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [X] Breaking changes are documented in the `README.md`
- [X] Templating unittests are added
Co-authored-by: Remo Geissbühler <git@remogeissbuehler.ch>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/597
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: remogeissbuehler <remogeissbuehler@noreply.gitea.com>
Co-committed-by: remogeissbuehler <remogeissbuehler@noreply.gitea.com>
### Benefits
Less image pulls.
### Additional information
committed via GUI - so no signature on first commit.
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/568
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
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>
### Description of the change
This PR is a continuation of the work done by @dgershman in [534](https://gitea.com/gitea/helm-chart/pulls/534), to allow users to override the image from the default rootless behavior of appending `-rootless` to the end of the image tag.
### Benefits
Allows more flexibility to use externally maintained images that are rootless but don't follow the `-rootless` tag convention.
### Applicable issues
- fixes#532
### Additional information
No breaking changes. This does not affect the `image.rootless` conditional checks or the current behavior if someone still wants to rely on the chart to append `-rootless`.
### Checklist
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [x] Breaking changes are documented in the `README.md`
- [x] Templating unittests are added
Co-authored-by: TristanHoladay <40547442+TristanHoladay@users.noreply.github.com>
Co-authored-by: pat-s <pat-s@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/550
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: TristanHoladay <tristanholaday@noreply.gitea.com>
Co-committed-by: TristanHoladay <tristanholaday@noreply.gitea.com>
### Description of the change
Update default params of chart dependencies. Tested with multiple upgrades and fresh installations.
Using no password auth for redis simplifies things for basic installations. Production installations should properly configure auth as they need it.
### Benefits
To avoid/solve upgrading issues as in #407 and #472
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/473
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
# 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>
### Description of the change
This adds a new values object `serviceAccount`, that allows creating a dedicated ServiceAccount with the Helm Release into the cluster. It supports all common options like labels, annotations, name override (or referring to an externally created ServiceAccount), auto-mount token, image pull secrets.
It supersedes the stale PR #357.
### Benefits
Users can deploy Gitea with more fine-tuned security settings.
### Applicable issues
- related to #448
### Additional information
I've bumped the helm-unittest plugin in the CI build, to be able to use the `exists` and `notExists` feature in the new tests.
### Checklist
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/451
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Signed-off-by: Cyril Jouve <jv.cyril@gmail.com>
<!--
Before you open the request please review the following guidelines and tips to help it be more easily integrated:
- Describe the scope of your change - i.e. what the change does.
- Describe any known limitations with your change.
- Please run any tests or examples that can exercise your modified code.
Thank you for contributing! We will try to review, test and integrate the change as soon as we can.
-->
### Description of the change
<!-- Describe the scope of your change - i.e. what the change does. -->
add a new value `extraDeploy` to add arbitrary resources
inspired by bitnami charts ([example](https://github.com/bitnami/charts/blob/main/bitnami/postgresql/values.yaml#L58)
### Benefits
<!-- What benefits will be realized by the code change? -->
with the change, I can deploy additional resources and keep them consistent with the chart (reuse macro, same labels, etc)., same workflow (helm upgrade), etc
### Possible drawbacks
<!-- Describe any known limitations with your change -->
### Additional information
<!-- If there's anything else that's important and relevant to your pull request, mention that information here. Please remove this section if it remains empty. -->
### Checklist
<!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] -->
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/441
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: Cyril Jouve <jv.cyril@gmail.com>
Co-committed-by: Cyril Jouve <jv.cyril@gmail.com>
Supersedes stalled #362
I opted for defining `requests` while leaving `limits` open. This might help for scheduling without restricting performance during init.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/423
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
@justusbunsi to end my formatting mess... ;)
I am not fully sure myself about the linebreaks in `values.yaml` but I don't think there's an easy way to change that behavior.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/413
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
And allow overriding the `image` section so users could possible also use other image tags.
fix#285
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/422
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
As discussed in Discord.
Supersedes #412 and #407.
**⚠️ BREAKING**
Users depending on the built-in MySQL or MariaDB chart have to switch to an self-managed database, or Postgres
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/417
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Reviewed-by: John Olheiser <john+gitea@jolheiser.com>
Reviewed-by: yardenshoham <yardenshoham@noreply.gitea.io>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
See discussion in #387
Upgrade notes to Chart v11.x and Postgres 14.x: https://docs.bitnami.com/kubernetes/infrastructure/postgresql/administration/upgrade/
The current version in Gitea is using `11.11.0-debian-10-r62` from 2021-04.
Bumping the chart to the latest (v12.x) would use the image `15.2.0-debian-11-r14` which would be a jump from postgres 11 to postgres 15. There are no specific notes for the v12.x chart release, hence we might be able to just go to 12.x directly.
There have been some param renamings which I've reflected in the README.
**⚠️ BREAKING**
Users have to migrate their Postgres DB by e.g. restoring a previously created database dump into a clean installation.
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/391
Reviewed-by: techknowlogick <techknowlogick@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
### Description of the change
Make the test-connection Pod optional and override the wget container's image.
### Benefits
Allows users to enable/disabled the test-connection Pod and override the wget container's image.
### Checklist
- [X] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [X] Breaking changes are documented in the `README.md`
Co-authored-by: Umer Anwar <umer.anwar@nuance.com>
Co-authored-by: ooms97 <anwarumer97@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/360
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: ooms97 <ooms97@noreply.gitea.io>
Co-committed-by: ooms97 <ooms97@noreply.gitea.io>
### Description of the change
It is required to add custom mapping between hostnames and IP addresses for the gitea pods to be able to access external services like oauth providers or webhook servers.
It is common to take global variables for the entires and set them using hostAliases in the pod template.
### Benefits
Give us more flexibility when using gitea in various network environments.
### Applicable issues
- fixes#400
### Checklist
- [X] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
Co-authored-by: Taekyun Kim <tkq.kim@samsung.com>
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/401
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: podain77 <podain77@noreply.gitea.io>
Co-committed-by: podain77 <podain77@noreply.gitea.io>
This reverts d5ce1a47eaad935ea709b7a03bfdf6c69bac8f32 and therefore adds the GPG feature back into main.
As it is a breaking change, this PR now also contains the required upgrade notes.
Closes#107 again.
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/374
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: John Olheiser <john+gitea@jolheiser.com>
### Description of the change
Corrects the spelling of the word deprecated.
### Benefits
Documentation free of misspelled words is more likely to be viewed as "professional".
### Possible drawbacks
None that I can think of
### Applicable issues
- fixes#393
### Additional information
There may be other misspelled words or incorrectly phrased passages that aren't addressed in this PR.
For reference, see the online dictionary for the correct spelling of deprecated.
https://www.merriam-webster.com/dictionary/deprecated
### Checklist
- [X] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
- [X] Breaking changes are documented in the `README.md`
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/394
Reviewed-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: robv89r <robv8r@noreply.gitea.io>
Co-committed-by: robv89r <robv8r@noreply.gitea.io>
Feature #343 happens to be a breaking change when enabling `.Values.signing` but not specifying
any of the new private key properties. Tag `v6.0.2` is therefore not following semantic versioning.
This temporarily reverts commit b8f0310c43bd71dd48ac92b70d8ebdb94d43c29b and a fix-up commit 57a1cd27d9a6cc014f425fabeadb0db34f242b0e
to retag 6.0.2 as 6.0.3.
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/373
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
### Description of the change
This PR adds support for gpg key setup. It allows to pass the gpg private key content inline inside `values.yaml` or refer to an existing secret containing the key content data.
### Benefits
Administrators don't need to manually setup the gpg environment from inside a running container. It also eliminates the breaking change of Gitea 1.17 regarding `[git].HOME` as the `GNUPGHOME` environment variable is used consistently to relocate the `.gnupg` directory to its former location.
### Applicable issues
- fixes#107
### Additional information
This PR add the first unit tests to this Helm Chart, ensuring templating integrity for signing related configuration.
### Checklist
- [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm)
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/343
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Description of the change
Add support for a new value: dnsConfig, to be passed to the statefulset pod template configuration.
Default is {}, and does not change anything from current default pod configuration.
Benefits
Ability to fix some issues encountered with Alpine-based docker images, which may break DNS resolving on some clusters.
In particular, this allows to lower the ndots value, which fixes DNS resolving of FQDNs.
dnsConfig:
options:
- name: ndots
value: "1"
Also, with this setting, one can set other parameters to finely tune DNS configuration for Gitea pods, if needed:
https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config
Possible drawbacks
None.
Additional information
Some relevant links about the issue this setting allows to fix:
https://stackoverflow.com/questions/65181012/does-alpine-have-known-dns-issue-within-kuberneteshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9017
Checklist
Parameters are documented in the values.yaml and added to the README.md using readme-generator-for-helm
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/329
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Co-authored-by: dek <dek@noreply.gitea.io>
Co-committed-by: dek <dek@noreply.gitea.io>
To enable access to e.g. the SSH port by IPv6, the selection of ipFamilyPolicy and ipFamilies service attributes is necessary. Enable the possibility to configure these by helm values.
Co-authored-by: Sven Fischer <sven@leiderfischer.de>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/313
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Reviewed-by: luhahn <luhahn@noreply.gitea.io>
Co-authored-by: svenihoney <svenihoney@noreply.gitea.io>
Co-committed-by: svenihoney <svenihoney@noreply.gitea.io>
Fixes#314
Right now, the gitea StatefulSet does not allow any annotations to be configured via the helmchart - see https://gitea.com/gitea/helm-chart/src/tag/v5.0.4/templates/gitea/statefulset.yaml#L4-L6
My use case:
I am trying to use Reloader (https://github.com/stakater/Reloader) so that I can configure my values.yaml such that i can set some annotations on the StatefulSet and thus Reloader can rollout a restart of gitea StatefulSet whenever a watched secret or configmap is updated.
Co-authored-by: Tarun Gupta Akirala <tarugupta.92@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/315
Reviewed-by: techknowlogick <techknowlogick@gitea.io>
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: takirala <takirala@noreply.gitea.io>
Co-committed-by: takirala <takirala@noreply.gitea.io>
This PR improves the handling and injection into _app.ini_ of user defined environment variables via env-to-ini script.
Fixes#297
Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/298
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io>
Reviewed-by: 6543 <6543@obermui.de>
