reinoud/mirror-forgejo-helm
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Temporary revert GPG feature for semver based retagging (#373)

Browse source 
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 b8f0310c43 and a fix-up commit 57a1cd27d9
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>
This commit is contained in:
justusbunsi 2022-10-21 00:35:19 +08:00
parent 57a1cd27d9
commit d5ce1a47ea
18 changed files with 22 additions and 440 deletions
Download patch file Download diff file Expand all files Collapse all files

71
README.md
View file

@ -41,6 +41,24 @@ 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 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
```
## Examples
### Gitea Configuration
@ -507,49 +525,6 @@ gitea:
...
```
## 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
@ -694,12 +669,10 @@ gitea:
### Signing
| 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 Gitea actions | `""` |
| `signing.existingSecret` | Use an existing secret to store the value of `signing.privateKey` | `""` |
| Name | Description | Value |
| ----------------- | ---------------------------- | ------------------ |
| `signing.enabled` | Enable commit/action signing | `false` |
| `signing.gpgHome` | GPG home directory | `/data/git/.gnupg` |
### Gitea