Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update release readme #1456

Merged
merged 1 commit into from
Apr 29, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 27 additions & 31 deletions release/README.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
# Release

This directory contain the files and scripts to run a cosign release.
This directory contain the files and scripts to run a Rekor release.

# Cutting a Rekor Release

1. Release notes: Create a PR to update and review release notes in CHANGELOG.md.
- Check merged pull requests since the last release and make sure enhancements, bug fixes, and authors are reflected in the notes.

Check merged pull requests since the last release and make sure enhancements, bug fixes, and authors are reflected in the notes.

You can get a list of pull requests since the last release by substituting in the date of the last release and running:

Expand All @@ -19,46 +20,41 @@ and a list of authors by running:
git log --pretty="* %an" --after="YYYY-MM-DD" | sort -u
```

2. Tag the repository
2. Open a Pull Request to update CHANGELOG.md

3. Tag the repository

**WARNING**: Tags should not be updated to a new ref or deleted/recreated after creation. Go provides a [checksum database](https://sum.golang.org/)
that persists an immutable mapping between version and ref, and updating the tag will break clients that have already downloaded the release.

```shell
$ export RELEASE_TAG=<release version, eg "v1.1.0">
$ export RELEASE_TAG=<release version, eg "v2.0.2">
$ git tag -s ${RELEASE_TAG} -m "${RELEASE_TAG}"
$ git push origin ${RELEASE_TAG}
$ git push upstream ${RELEASE_TAG}
```

3. Submit the cloudbuild Job using the following command:
Note that `upstream` should be the upstream `sigstore/rekor` repository. You may have to change this if you've configured remotes.

```shell
$ gcloud builds submit --config <PATH_TO_CLOUDBUILD> \
--substitutions _GIT_TAG=<_GIT_TAG>,_TOOL_ORG=sigstore,_TOOL_REPO=rekor,_STORAGE_LOCATION=rekor-releases,_KEY_RING=<KEY_RING>,_KEY_NAME=<KEY_NAME>,_GITHUB_USER=<GITHUB_USER> \
--project <GCP_PROJECT>
```
4. Then go to the `Actions` tab and click on the [Cut Release workflow](https://github.com/sigstore/rekor/actions/workflows/cut-release.yml). Note you need
to be in [this list](https://github.com/sigstore/sigstore/blob/main/.github/workflows/reusable-release.yml#L45) to trigger this workflow.

Click to run a workflow and insert the following parameters ("Cosign" is correct, this refers to the artifact signing key):

Where:
- `Release tag`: the tag that use pushed for the release
- `Key ring for cosign key`: the value is `release-cosign`
- `Key name for cosign key`: the value is `cosign`

- `PATH_TO_CLOUDBUILD` is the path where the cloudbuild.yaml can be found.
- `GCP_PROJECT` is the GCP project where we will run the job.
- `_GIT_TAG` is the release version we are publishing, this will also create the GitHub Tag.
- `_TOOL_ORG` is the GitHub Org we will use. Default `sigstore`.
- `_TOOL_REPO` is the repository we will use to clone. Default `cosign`.
- `_STORAGE_LOCATION` where to push the built artifacts. Default `cosign-releases`.
- `_KEY_RING` key ring name of your cosign key.
- `_KEY_NAME` key name of your cosign key.
- `_KEY_VERSION` version of the key storaged in KMS. Default `1`.
- `_KEY_LOCATION` location in GCP where the key is storaged. Default `global`.
- `_GITHUB_USER` GitHub user to authenticate for pushing to GHCR.
That will trigger a CloudBuild job and will run the release using `goreleaser`, which will publish images to
`gcr.io` and `ghcr.io`, and the binaries will be available in the GitHub release.

4. When the job finish, whithout issues, you should be able to see in GitHub a draft release.
You now can review the release, make any changes if needed and then publish to make it an official release.
If you have permissions to access the project, you can follow the CloudBuild job in the `projectsigstore`(https://console.cloud.google.com/cloud-build/builds?project=projectsigstore) GCP Project.

5. Send an annoucement email to `sigstore-dev@googlegroups.com` mailling list
As the last step of the CloudBuild job, `goreleaser` will create a `draft release` in GitHub.

6. Tweet about the new release with a fun new trigonometry pun!
5. Navigate to the `Draft Release` in the Github repository. Click the `Publish Release` button to make the Release available.

7. Honk!
You might want/need to add any extra notes/breaking changes notices, upgrade paths.

#### After the release:
6. Post on the `#general` and `#rekor` Slack channels.

* Add a pending new section in CHANGELOG.md to set up for the next release
* Create a new GitHub Milestone
7. If it's a significant release, send an announcement email to sigstore-dev@googlegroups.com mailing list.