This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| [postgresql-ha](https://github.com/bitnami/charts) ([source](https://github.com/bitnami/charts/tree/HEAD/bitnami/postgresql-ha)) | major | `11.9.4` -> `12.3.1` |
---
### Configuration
📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - "before 4am" (UTC).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy44LjEiLCJ1cGRhdGVkSW5WZXIiOiIzNy43Ny4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/528
Co-authored-by: Renovate Bot <renovate-bot@gitea.com>
Co-committed-by: Renovate Bot <renovate-bot@gitea.com>
While working on #409, I noticed that some unittests contains either
invalid assertion methods (`isNotEmpty`) or invalid properties (`any`)
for a specific assertion method (`notContains`).
As our tests pass - and I have ensured that they can fail - this seems
related to the YAML schema validation in the IDE.
I've noticed that `isNotEmpty` was replaced by `isNotNullOrEmpty`[^1]
in version v0.3.2[^2]. At least from a schema validation point of view.
It is still working. Maybe deprecated? I don't know.
Regarding the `any` property, the documentation seems incorrect. I've
filed a PR for it[^3]. As soon as that PR is merged and released, we
could probably validate the test YAML files in our PR workflow.
Last, since we renovate the used helm-unittest version, we should also
renovate the used YAML schema file.
[^1]: https://github.com/helm-unittest/helm-unittest/pull/139
[^2]: https://github.com/helm-unittest/helm-unittest/releases/tag/v0.3.2
[^3]: https://github.com/helm-unittest/helm-unittest/pull/243
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/570
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
As seen in #507 and #569, there is no guarantee for us that minor
dependency updates are actually minor updates for the dependent
application itself. The Chart version might be minor - and therefore
automatically merged when build is green - but the used Docker image
inside the Chart could still be a major version change.
To effectively prevent such automerge when the application major version
changes, there is now a test file that has the currently used major
versions hard-coded. In case of an actual major bump, this file has to
be adjusted.
Looking at `redis-cluster`, there might be several major Chart versions
with the same major application version.
This PR is related to #409 but does not fully resolve it.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/571
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
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>
### 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 supersedes #359 by fixing the fallback domain value when no ingress host is defined.
Memcached is not used anymore. PostgreSQL macro has already been fixed otherwise.
### Checklist
- [x] Templating unittests are added
Co-authored-by: pat-s <pat-s@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/560
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
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>
As 11.9.8 included (by mistake) a major version bump from 15 -> 16
https://github.com/bitnami/charts/issues/19596
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/541
Reviewed-by: justusbunsi <justusbunsi@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
The `postgresql-ha` provides a dedicated deployment and service called `pgpool`. This application is a proxy that routes the db queries to the active database replica. There's a note about that in their README[^1].
Issue #502 is a side-effect of not using that proxy.
### Possible drawbacks
Using the Charts' default configuration, the `pgpool` deployment has 1 replica, making this a single-point of failure. But users can change the related `postgresql-ha.pgpool.replicaCount` to their needs.
### Applicable issues
- fixes#502
### Checklist
- [x] Templating unittests are added
[^1]: https://github.com/bitnami/charts/blob/main/bitnami/postgresql-ha/templates/postgresql/statefulset.yaml#introduction
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/542
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
This adds a `.vscode` folder with recommended extensions and some useful settings like unittest schema validation.
The `.vscode` folder is already helm ignored during packaging.
### Possible drawbacks
We would have to be careful about PR changes in that directory.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/536
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.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>
As title. I think using that label helps categorizing Pull Requests.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/538
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>
Relates to #524, #515.
Both examples have been tested on a k8s dev install locally by deploying in a fresh namespace.
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/531
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@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
Update README with information how to configure renovate to update digest for gitea charts.
### Benefits
Automatic digest updates for people using renovate.
Co-authored-by: Michał Małyska <999598+mmalyska@users.noreply.github.com>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/514
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: mmalyska <mmalyska@noreply.gitea.com>
Co-committed-by: mmalyska <mmalyska@noreply.gitea.com>
### Description of the change
Introducing `tpl` function on variables related to hostname in `./templates/gitea/ingress.yaml`
### Benefits
The change is intending to support the following syntax in a values.yaml such as:
```
global:
giteaHostName: "gitea.my-org.com"
ingress:
enabled: true
hosts:
- host: "{{ .Values.global.giteaHostName }}"
paths:
- path: /
pathType: Prefix
tls:
- secretName: gitea-tls
hosts:
- "{{ .Values.global.giteaHostName }}"
```
### Possible drawbacks
N/A
### Applicable issues
N/A
### Additional information
N/A
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/498
Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com>
Co-authored-by: Ceddaerrix <ceddaerrix@noreply.gitea.com>
Co-committed-by: Ceddaerrix <ceddaerrix@noreply.gitea.com>
