### Description of the change
Add options to values.yaml to make chart easier to install in restricted openshift environments
### Benefits
more people can run this
### 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)
- [ ] Breaking changes are documented in the `README.md`
- [x] Helm templating unittests are added (required when changing anything in `templates` folder)
- [ ] Bash unittests are added (required when changing anything in `scripts` folder)
- [x] All added template resources MUST render a namespace in metadata
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1063
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.com>
Co-committed-by: techknowlogick <techknowlogick@gitea.com>
### Description of the change
This change fixes an intermittent failure in the init password-reset flow caused by the CLI feature probe used to detect `--must-change-password` support.
The current probe uses:
`gitea admin user change-password --help | grep -qF -- '--must-change-password'`
Because `grep -q` exits immediately after the first match, it can close the pipe while gitea is still writing help output. In that case, gitea may return broken pipe.
This is timing-dependent, so it only reproduces sometimes with the same binary.
This PR replaces that check with a form that consumes the full output before exiting, avoiding premature pipe closure.
### Benefits
- Prevents intermittent broken pipe failures during init
- Makes password-reset capability detection deterministic
### Applicable issues
- Fixes#1051
### Additional information
No test update was required for this change.
The fix only adjusts the shell pipeline used in the rendered init script to avoid an intermittent broken pipe during the `--must-change-password` capability check. There are currently no existing Helm or bash unit tests covering this specific command path in the chart, and this change does not alter chart values, rendered resource structure, or template interfaces.
### Checklist
- [x] Bash unittests are added (required when changing anything in `scripts` folder)
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1052
Co-authored-by: alexandru-marianlita <alexandru-marian.lita@spirent.com>
Co-committed-by: alexandru-marianlita <alexandru-marian.lita@spirent.com>
For various internal reasons we're not currently running gitea via the Helm chart right now, so I'm not in the same position I was before to review and test patches.
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1047
Co-authored-by: Ross Golder <ross@golder.org>
Co-committed-by: Ross Golder <ross@golder.org>
### Description of the change
Gitea supports providing DB and Redis/ValKey secrets via env variables, current chart requires DB and Redis/ ValKey credentials reading from k8s secret as per below values.yaml snippet. This approach requires secret to be created beforehand.
```
- name: GITEA__database__USER
valueFrom:
secretKeyRef:
name: gitea-ha
key: db_user
- name: GITEA__database__PASSWD
valueFrom:
secretKeyRef:
name: gitea-ha
key: db_password
```
Other approach is to provide the credentials in values.yaml which isnt secure.
A bash variable file can be created by using vault injector like this, which then can be sourced while running `config_environment.sh` in `init-app-ini`
```
GITEA__database__NAME=gitea
GITEA__database__USER=gitea_user
```
Support to read env variables from file
Reference: https://developer.hashicorp.com/vault/docs/deploy/kubernetes/injector/examples#environment-variable-example
### Benefits
Support to read env variables from file created by vault injector for DB and redis/ valkey credentials
Support to set gitea admin user and credentials via env variables from file created by vault injector
### Possible drawbacks
N/A
### âš BREAKING
No breaking changes
### 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: techknowlogick <techknowlogick@gitea.com>
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/993
Co-authored-by: deepakdeore2004 <deepakdeore2004@noreply.gitea.com>
Co-committed-by: deepakdeore2004 <deepakdeore2004@noreply.gitea.com>
### Description of the change
I've added the root label to the valkey domain that is searched by nc in the `configure_gitea.sh` script.
Here is an example of what the `test_valkey_connection` function will look like to the `configure-gitea` container:
```
function test_valkey_connection() {
local RETRY=0
local MAX=30
echo 'Wait for valkey to become avialable...'
until [ "${RETRY}" -ge "${MAX}" ]; do
nc -vz -w2 gitea-dev-valkey-cluster-headless.gitea-dev.svc.cluster.local. 6379 && break
RETRY=$[${RETRY}+1]
echo "...not ready yet (${RETRY}/${MAX})"
done
if [ "${RETRY}" -ge "${MAX}" ]; then
echo "Valkey not reachable after '${MAX}' attempts!"
exit 1
fi
}
```
### Benefits
If a search domain is set in resolve.conf, nc will append that root domain to the lookup, causing the lookup to fail. This will allow users to have a search domain set without causing the configure script to fail.
### Possible drawbacks
I don't believe there are any drawbacks, but let me know if I'm wrong.
### Applicable issues
gitea/helm-gitea#972
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/982
Reviewed-by: Markus Pesch <volker.raschek@noreply.gitea.com>
Co-authored-by: David Chatterton <david@davidchatterton.com>
Co-committed-by: David Chatterton <david@davidchatterton.com>
The following patch inherits the default values of the dependencies like
postgresql-ha, postgresql, valkey-cluster and valkey to disable persistent
storage.
For users, this is more obvious than having to look up the configuration options
in the dependencies or subcharts themselves.
This PR removes the inclusion of `deployment.labels` in the Deployment's `selector.matchLabels` field.
## Changes
- Removed the conditional block that adds `deployment.labels` to `selector.matchLabels`
- This ensures the selector remains immutable and only contains pod-identifying labels
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/1011
Reviewed-by: Markus Pesch <volker.raschek@noreply.gitea.com>
Co-authored-by: Tarun Gaba <tarun.gaba7@gmail.com>
Co-committed-by: Tarun Gaba <tarun.gaba7@gmail.com>
techknowlogick
volker.raschek
