Using `helm dependency update` may result in unwillingly updating the
dependencies while cutting a release. I wasn't able to do so. Most
likely due to the dependency pinning in Chart.yaml and Chart.lock.
Based on Helm documentation, `update` uses Chart.yaml[^1] while `build`
uses Chart.lock[^2].
All in all it is safer to use `helm dependency build`. :D
[^1]: https://helm.sh/docs/helm/helm_dependency_update/
[^2]: https://helm.sh/docs/helm/helm_dependency_build/
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/563
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
There is a regression that prevents us from going directly to 0.3.5.
To prevent the upcoming Renovate PR for 0.3.5 being stuck until 0.3.6,
we can use 0.3.4 until a working version is released.
The Renovate PR for 0.3.5 can then be closed directly so that Renovate
ignores that version.
https://github.com/helm-unittest/helm-unittest/issues/219
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/537
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
### Description of the change
We are affected by a regression of a Helm bug from May 2023. I've tested
the Helm versions 3.13.1, 3.13.0 and 3.12.3. Both 3.13.x are affected.
3.12.3 works. So let's downgrade and drop the docker login in PR builds.
I've also switched the `apt install helm` with an official `alpine/helm`
image I am using at work. Pinning the helm version and receiving updates
helps us identifying such issues in the future.
For the release workflow I was a bit more reluctant with changes, since
I cannot easily test them. That's why I just pinned the Helm version.
Renovate will provide one PR changing both files because it's the same
dependency (alpine/helm) from the same datasource (docker).
https://github.com/helm/helm/issues/12062
### Applicable issues
- implicitly fixes#527
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/535
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>
Same as for the release workflow.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/526
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>
fix#31
First stab, need to iterate most likely.
@techknowlogick @lunny Could one of you add the GPG secrets here so the signing can be tested?
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/427
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
@lunny
It still looks like that the IAM user does not have enough permissions for the S3 sync operation.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/438
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
