Publishing a New kube-bind Release
Note
You currently need write access to the kube-bind/kube-bind repository to perform these tasks.
Create git Tags
Prerequisite - Make Sure You Have a GPG Signing Key
- https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key
- https://docs.github.com/en/authentication/managing-commit-signature-verification/adding-a-gpg-key-to-your-github-account
- https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key
Create the Tags
kube-bind has 3 go modules, and a unique tag is needed for each module every time we create a new release.
git fetch
from the main kube-bind repository (kube-bind/kube-bind) to ensure you have the latest commits- Tag the main module
- If your git remote for kube-bind/kube-bind is named something other than
upstream
, changeREF
accordingly -
If you are creating a release from a release branch, change
main
inREF
accordingly, or you can makeREF
a commit hash. -
Tag the
sdk
module, following the same logic as above forREF
andTAG
-
Tag the
cli
module, following the same logic as above forREF
andTAG
Push the Tags
If it's a New Minor Version
If this is the first release of a new minor version (e.g. the last release was v0.7.x, and you are releasing the first
0.8.x version), follow the following steps.
Otherwise, you can skip to [Generate release notes](#generate-release-notes).
Generate Release Notes
To generate release notes from the information in PR descriptions you should use Kubernetes' release-notes tool.
This tool will use the release-notes
blocks in PR descriptions and the kind/
labels on those PRs to find user-facing changes and categorize them.
You can run the command below to install the latest version of it:
To use release-notes
you will need to generate a GitHub API token (Settings -> Developers settings -> Personal access tokens -> Fine-grained tokens). A token with Public Repositories (read-only) repository access and no further permissions is sufficient. Store the token somewhere safe and export it as GITHUB_TOKEN
environment variable.
Then, run run the release-notes
tool (set PREV_VERSION
to the version released before the one you have just released).
TAG=v0.5.0
PREV_TAG=v0.4.8
release-notes \
--required-author='' \
--org kube-bind \
--repo kube-bind \
--branch main \
--start-rev $PREV_TAG \
--end-rev $TAG \
--output CHANGELOG.md
Don't commit the CHANGELOG.md
to the repository, just keep it around to update the release on GitHub (next step).
Review/Edit/Publish the Release in GitHub
The goreleaser workflow automatically creates a draft GitHub release for each tag.
- Navigate to the draft release for the tag you just pushed. You'll be able to find it under the releases page.
- If the release notes have been pre-populated, delete them.
- Copy release notes from the
CHANGELOG.md
file you generated in the previous step. - Publish the release.
Trigger Documentation Deployment
Documentation for the respective release branch needs to be triggered manually after the release branch has been pushed.
- Navigate to the Generate and push docs GitHub Action.
- Hit the "Run forkflow" button, run workflow against
release-$VERSION
. - Make sure the triggered workflow ran and deployed a new version of the documentation to https://docs.kube-bind.io/main/.
Notify
- Create an email addressed to kube-bind-dev@googlegroups.com with:
- Subject:
[release] <version>
e.g.[release] v0.5.0
- In the body, include noteworthy changes
- Provide a link to the release in GitHub for the full release notes
- Subject:
- Post a message in the #kube-bind Slack channel