Skip to content

Commit

Permalink
Update release readme (sigstore#2942)
Browse files Browse the repository at this point in the history
Syncing this with the internal release notes, which now use the reusable workflow rather than calling cloud build. Also adds a warning about tag mutation.

Signed-off-by: Hayden B <[email protected]>
  • Loading branch information
haydentherapper authored Apr 28, 2023
1 parent cbb8af6 commit e7bc78b
Showing 1 changed file with 26 additions and 31 deletions.
57 changes: 26 additions & 31 deletions release/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,11 @@

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

# Cutting a Sigstore Release
# Cutting a Cosign 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,47 +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.4.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}
```

Note that `upstream` should be the upstream `sigstore/cosign` repository. You may have to change this if you've configured remotes.

2. Submit the cloudbuild Job using the following command:

```shell
$ gcloud builds submit --config <PATH_TO_CLOUDBUILD> \
--substitutions _GIT_TAG=${RELEASE_TAG},_TOOL_ORG=sigstore,_TOOL_REPO=cosign,_STORAGE_LOCATION=cosign-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/cosign/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.

Where:
Click to run a workflow and insert the following parameters:

- `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.
- `_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 stored in KMS. Default `1`.
- `_KEY_LOCATION` location in GCP where the key is stored. Default `global`.
- `_GITHUB_USER` GitHub user to authenticate for pushing to GHCR.
- `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`

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.

3. When the job finish, without 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.

4. Send an announcement email to `[email protected]` mailing list
As the last step of the CloudBuild job, `goreleaser` will create a `draft release` in GitHub.

5. 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.

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

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

* Add a pending new section in CHANGELOG.md to set up for the next release
7. If it's a significant release, send an announcement email to [email protected] mailing list.

0 comments on commit e7bc78b

Please sign in to comment.