mirror of
https://github.com/ossf/scorecard.git
synced 2024-10-26 10:28:10 +03:00
92 lines
3.3 KiB
Markdown
92 lines
3.3 KiB
Markdown
|
# Releasing Scorecard
|
||
|
|
||
|
This is a draft document to describe the release process for Scorecard
|
||
|
|
||
|
(If there are improvements you'd like to see, please comment on the
|
||
|
[tracking issue](https://github.com/ossf/scorecard/issues/1676) or issue a
|
||
|
pull request to discuss.)
|
||
|
|
||
|
- [Tracking](#tracking)
|
||
|
- [Preparing the release](#preparing-the-release)
|
||
|
- [Validate tests](#validate-tests)
|
||
|
- [Drafting release notes](#drafting-release-notes)
|
||
|
- [Release](#release)
|
||
|
- [Create a tag](#create-a-tag)
|
||
|
- [Create a GitHub release](#create-a-github-release)
|
||
|
- [Validate Release](#validate-release)
|
||
|
|
||
|
## Tracking
|
||
|
|
||
|
As the first task, a Release Manager should open a tracking issue for the
|
||
|
release.
|
||
|
|
||
|
We don't currently have a template for releasing, but the following
|
||
|
[issue](https://github.com/ossf/scorecard-action/issues/97) is a good example
|
||
|
to draw inspiration from.
|
||
|
|
||
|
We're not striving for perfection with the template, but the tracking issue
|
||
|
will serve as a reference point to aggregate feedback, so try your best to be
|
||
|
as descriptive as possible.
|
||
|
|
||
|
## Preparing the release
|
||
|
|
||
|
This section covers changes that need to be issued as a pull request and should
|
||
|
be merged before releasing the scorecard GitHub Action.
|
||
|
|
||
|
### Validate tests
|
||
|
|
||
|
Check the unit tests and integration tests are passing for the planned release commit, either locally or for the GitHub workflows.
|
||
|
|
||
|
## Drafting release notes
|
||
|
|
||
|
Release notes are a semi-automated process. We often start by opening [drafting a new release on GitHub](https://github.com/ossf/scorecard/releases/new).
|
||
|
You can select to create a new tag on publish, and auto-generate some notes by clicking `Generate release notes`.
|
||
|
This provides a good start, but no one wants to see a wave of dependabot commits, so filter them out.
|
||
|
Try to focus on the PRs that affect users or behavior, not dependency updates or CI changes.
|
||
|
|
||
|
Using the Kubernetes `release-notes` tool can also be helpful if PR authors filled out the user-facing change section.
|
||
|
```console
|
||
|
release-notes --org ossf --repo scorecard --branch main \
|
||
|
--dependencies=false \
|
||
|
--required-author "" \
|
||
|
--start-rev <previous release tag> \
|
||
|
--end-rev <commit to be tagged>
|
||
|
```
|
||
|
|
||
|
Note: This doesn't always grab the right value when PR bodies have multiple code blocks in them.
|
||
|
|
||
|
Save your draft when satisfied and share it with other maintainers for feedback, if possible.
|
||
|
|
||
|
## Release
|
||
|
|
||
|
### Create a tag
|
||
|
|
||
|
The GitHub release process supports creating a tag on publish, but prefer signing the tag when possible.
|
||
|
In this example, we're releasing a hypothetical `v100.0.0` at the desired commit SHA `SHA`:
|
||
|
|
||
|
```console
|
||
|
git remote update
|
||
|
git checkout `SHA`
|
||
|
git tag -s -m "v100.0.0" v100.0.0
|
||
|
git push <upstream> v100.0.0
|
||
|
```
|
||
|
|
||
|
### Create a GitHub release
|
||
|
|
||
|
Revisit the draft release you created earlier, and ensure it's using the correct tag.
|
||
|
|
||
|
Release title: `<tag>`
|
||
|
|
||
|
The release notes will be the notes you drafted in the previous step.
|
||
|
|
||
|
Ensure the release is marked as the latest release, if appropriate.
|
||
|
|
||
|
Click `Publish release`.
|
||
|
|
||
|
## Validate Release
|
||
|
|
||
|
When a new tag is pushed, our GitHub Actions will create a release using `goreleaser`.
|
||
|
Confirm the workflow ran without issues. Check the release again to verify the artifacts and provenance have been added.
|
||
|
|
||
|
If any issues were encountered, fixes must be issued under a new release/tag as Go releases are immutable.
|