Skip to content

Commit ee6eee6

Browse files
authored
Merge pull request #588 from estroz/release-signing-process
Release signing process
2 parents c0f6021 + 900c162 commit ee6eee6

File tree

2 files changed

+18
-8
lines changed

2 files changed

+18
-8
lines changed

Makefile

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -36,7 +36,7 @@ release_x86_64 := \
3636
build/operator-sdk-$(VERSION)-x86_64-linux-gnu \
3737
build/operator-sdk-$(VERSION)-x86_64-apple-darwin
3838

39-
release: clean $(release_x86_64)
39+
release: clean $(release_x86_64) $(release_x86_64:=.asc)
4040

4141
build/operator-sdk-%-x86_64-linux-gnu: GOARGS = GOOS=linux GOARCH=amd64
4242
build/operator-sdk-%-x86_64-apple-darwin: GOARGS = GOOS=darwin GOARCH=amd64

doc/release-versioning.md

Lines changed: 17 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,7 @@ Milestone labels have the form: `milestone-x.y.0`, where `x` and `y` are major a
1111
## Major versions
1212

1313
Major version changes can break compatibility between the previous major versions; they are not necessarily backwards or forwards compatible. SDK change targets include but are not limited to:
14+
1415
- `operator-sdk` command and sub-commands
1516
- Golang API
1617
- Formats of various yaml manifest files
@@ -47,8 +48,9 @@ $ git push origin "cherry-picked-change"
4748
# Releases
4849

4950
Making an Operator SDK release involves:
51+
5052
- Tagging and signing a git commit and pushing the tag to GitHub.
51-
- Building a release binary and uploading the binary to GitHub.
53+
- Building a release binary, signing the binary, and uploading both binary and signature to GitHub.
5254

5355
Releases can only be performed by [maintainers][doc-maintainers].
5456

@@ -64,26 +66,31 @@ Release binaries will be built for the `x86_64` architecture for both GNU Linux
6466

6567
Support for the Windows platform or any architecture other than `x86_64` is not on the roadmap at this time.
6668

67-
## Binaries
69+
## Binaries and signatures
70+
71+
Binaries will be signed using a maintainers' verified GitHub PGP key. Both binary and signature will be uploaded to the release. Ensure you import maintainer keys to verify release binaries.
72+
73+
Creating release binaries and signatures:
6874

69-
Creating release binaries:
7075
```bash
7176
$ ./release.sh "v${VERSION}"
7277
```
7378

79+
**Note**: you must have both [`git`][doc-git-default-key] and [`gpg`][doc-gpg-default-key] default PGP keys set locally for `release.sh` to run without error.
80+
7481
## Release tags
7582

7683
Every release will have a corresponding git tag.
7784

78-
Make sure you've [uploaded your GPG key][link-github-gpg-key-upload] and configured git to [use that signing key][link-git-config-gpg-key] either globally or for the Operator SDK repository. Note: the email the key is issued for must be the email you use for git.
85+
Make sure you've [uploaded your GPG key][link-github-gpg-key-upload] and configured git to [use that signing key][link-git-config-gpg-key] either globally or for the Operator SDK repository. Tagging will be handled by `release.sh`.
86+
87+
**Note**: the email the key is issued for must be the email you use for git.
7988

8089
```bash
8190
$ git config [--global] user.signingkey "$GPG_KEY_ID"
8291
$ git config [--global] user.email "$GPG_EMAIL"
8392
```
8493

85-
Tagging will be handled by `release.sh`.
86-
8794
## Release Notes
8895

8996
Release notes should be a thorough description of changes made to code, documentation, and design. Individual changes, such as bug fixes, should be given their own bullet point with a short description of what was changed. Issue links and handle of the developer who worked on the change should be included whenever possible.
@@ -157,6 +164,7 @@ $ gpg --recv-key ${KEY_ID}
157164
Now you should be able to verify the tags and/or binaries
158165
159166
## For maintainers
167+
160168
For new maintainers who have not done a release and do not have their gpg key on a public
161169
keyserver, you must add your public key to a keyserver. To do this, output your armored
162170
public key using this command:
@@ -173,7 +181,9 @@ key and you are ready to sign releases.
173181
[link-semver]:https://semver.org/
174182
[link-github-milestones]: https://help.github.com/articles/about-milestones/
175183
[doc-maintainers]:../MAINTAINERS
184+
[doc-git-default-key]:https://help.github.com/articles/telling-git-about-your-signing-key/
185+
[doc-gpg-default-key]:https://lists.gnupg.org/pipermail/gnupg-users/2001-September/010163.html
176186
[link-github-gpg-key-upload]:https://github.com/settings/keys
177187
[link-git-config-gpg-key]:https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
178188
[doc-kube-version]:https://github.com/operator-framework/operator-sdk#prerequisites
179-
[mit-keyserver]:https://pgp.mit.edu
189+
[mit-keyserver]:https://pgp.mit.edu

0 commit comments

Comments
 (0)