feat!: upstream changes (#47)

GPG feature has breaking changes

Co-authored-by: robv89r <robv8r@noreply.gitea.io>
Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Reviewed-on: https://codeberg.org/forgejo-contrib/forgejo-helm/pulls/47
This commit is contained in:
Michael Kriese 2023-01-19 13:45:32 +00:00
parent 94dc70c8d7
commit a0e6b1ad35
20 changed files with 467 additions and 30 deletions

View file

@ -37,24 +37,6 @@ of this document for major and breaking changes.
- Helm 3.0+
- PV provisioner for persistent data support
## Configure Commit Signing
When using the rootless image the gpg key folder was is not persistent by
default. If you consider using signed commits for internal Forgejo activities
(e.g. initial commit), you'd need to provide a signing key. Prior to
[PR186](https://gitea.com/gitea/helm-chart/pulls/186), imported keys had to be
re-imported once the container got replaced by another.
The mentioned PR introduced a new configuration object `signing` allowing you to
configure prerequisites for commit signing. By default this section is disabled
to maintain backwards compatibility.
```yaml
signing:
enabled: false
gpgHome: /data/git/.gnupg
```
## Examples
### Forgejo Configuration
@ -521,6 +503,49 @@ gitea:
existingSecret: gitea-oauth-secret
```
## Configure commit signing
When using the rootless image the gpg key folder is not persistent by
default. If you consider using signed commits for internal Gitea activities
(e.g. initial commit), you'd need to provide a signing key. Prior to
[PR186](https://gitea.com/gitea/helm-chart/pulls/186), imported keys had to be
re-imported once the container got replaced by another.
The mentioned PR introduced a new configuration object `signing` allowing you to
configure prerequisites for commit signing. By default this section is disabled
to maintain backwards compatibility.
```yaml
signing:
enabled: false
gpgHome: /data/git/.gnupg
```
Regardless of the used container image the `signing` object allows to specify a
private gpg key. Either using the `signing.privateKey` to define the key inline,
or refer to an existing secret containing the key data by using `signing.existingKey`.
```yaml
apiVersion: v1
kind: Secret
metadata:
name: custom-gitea-gpg-key
type: Opaque
stringData:
privateKey: |-
-----BEGIN PGP PRIVATE KEY BLOCK-----
...
-----END PGP PRIVATE KEY BLOCK-----
```
```yaml
signing:
existingSecret: custom-gitea-gpg-key
```
To use the gpg key, Gitea needs to be configured accordingly. A detailed description
can be found in the [official Gitea documentation](https://docs.gitea.io/en-us/signing/#general-configuration).
### Metrics and profiling
A Prometheus `/metrics` endpoint on the `HTTP_PORT` and `pprof` profiling
@ -665,10 +690,12 @@ gitea:
### Signing
| Name | Description | Value |
| ----------------- | ---------------------------- | ------------------ |
| `signing.enabled` | Enable commit/action signing | `false` |
| `signing.gpgHome` | GPG home directory | `/data/git/.gnupg` |
| Name | Description | Value |
| ------------------------ | ----------------------------------------------------------------- | ------------------ |
| `signing.enabled` | Enable commit/action signing | `false` |
| `signing.gpgHome` | GPG home directory | `/data/git/.gnupg` |
| `signing.privateKey` | Inline private gpg key for signed Forgejo actions | `""` |
| `signing.existingSecret` | Use an existing secret to store the value of `signing.privateKey` | `""` |
### Gitea