Skip to content

Commit

Permalink
Update the release issue template
Browse files Browse the repository at this point in the history 
Minor improvements / cleanups in the release issue template. Also update
RELEASE.md to simply point to the release issue template to avoid any
confusion.

Signed-off-by: Michi Mutsuzaki <michi@isovalent.com>
  • Loading branch information
@michi-covalent
michi-covalent committed Oct 7, 2024
1 parent 27a14aa commit e2230fd
Show file tree
Hide file tree
Showing 2 changed files with 14 additions and 222 deletions.
24 changes: 11 additions & 13 deletions .github/ISSUE_TEMPLATE/release.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,12 +5,6 @@ title: 'vX.Y.Z release'
---

- [ ] Install [`gh`](https://cli.github.com/) and authenticate with GitHub by running `gh auth login`.
- [ ] Install the latest [Cilium release tool]:

git clone https://github.com/cilium/release.git "$(go env GOPATH)/src/github.com/cilium/release"
cd $(go env GOPATH)/src/github.com/cilium/release
git checkout master && git pull && make
sudo install release /usr/local/bin

- [ ] Define `NEW_RELEASE` and `PREVIOUS_RELEASE` environment variables. For
example, if you are releasing a new Hubble CLI version based on
Expand All @@ -24,7 +18,7 @@ title: 'vX.Y.Z release'
git checkout main
git pull origin main
git switch -c pr/$USER/v$NEW_RELEASE-prep

- [ ] Check if `replace` directive in `go.mod` is in sync with `cilium/cilium`. Run:

curl https://raw.githubusercontent.com/cilium/cilium/$NEW_RELEASE/go.mod
Expand All @@ -37,9 +31,13 @@ title: 'vX.Y.Z release'
go mod tidy && go mod vendor && go mod verify
git add go.mod go.sum vendor

- [ ] Prepare release notes:
- [ ] Prepare release notes. You need to generate release notes from both
cilium/cilium and cilium/hubble repositories and manually combine them.

GITHUB_TOKEN=$(gh auth token) release changelog --base v$PREVIOUS_RELEASE --head v$NEW_RELEASE --repo cilium/cilium --label-filter hubble-cli
docker pull quay.io/cilium/release-tool:main
alias release='docker run -it --rm -e GITHUB_TOKEN=$(gh auth token) quay.io/cilium/release-tool:main'
release changelog --base v$PREVIOUS_RELEASE --head v$NEW_RELEASE --repo cilium/cilium --label-filter hubble-cli
release changelog --base v$PREVIOUS_RELEASE --head main --repo cilium/hubble

- [ ] Modify `CHANGELOG.md` with the generated release notes:

Expand All @@ -48,12 +46,12 @@ title: 'vX.Y.Z release'
git add CHANGELOG.md

- [ ] Push the prep branch and open a Pull Request against main branch.

git commit -s -m "Prepare for v$NEW_RELEASE release"
git push

Get the pull request reviewed and merged.

- [ ] Update your local checkout:

git checkout main
Expand All @@ -72,7 +70,7 @@ title: 'vX.Y.Z release'
git tag -s -a "v$NEW_RELEASE" -m "v$NEW_RELEASE" $COMMIT_SHA

Admire the tag you just created for 1 minute:

git show "v$NEW_RELEASE"

Then push the tag:
Expand All @@ -85,7 +83,7 @@ title: 'vX.Y.Z release'
- [ ] Find the release draft in the [Releases page]. Copy and paste release notes from
CHANGELOG.md, and click on `Publish release` button.
- [ ] Post a release announcement message in the [Cilium Slack #general channel]. Example:

Hubble CLI v0.8.2 is released 
Release notes and binaries: https://github.com/cilium/hubble/releases/tag/v0.8.2
Notable changes:
Expand Down
212 changes: 3 additions & 209 deletions RELEASE.md
View file
Original file line number Diff line number Diff line change
@@ -1,212 +1,6 @@
# RELEASE

Release process and checklist for `hubble`.
Create a GitHub issue using [the release issue template], and follow the
instructions in the GitHub issue.

## Prep the variables

These variables will be used in the commands throughout the README to allow
copy-pasting.

### Release hash

Identify which commit will serve as the release point.

New major and minor version with `.0` patch have to stem from the `main`
branch, while new patch releases have to stem from their respective minor
branches.

export RELEASE_HASH=<commit hash, i.e. 37c8023>

### Version

If releasing a new version 5.4.0 with the latest release being 5.3.8, for
example, they will look as follows:

export MAJOR=5
export MINOR=4
export PATCH=0
export LAST_RELEASE=5.3.8

## Create release branch

If a `.0` patch version is being created, a new `major.minor` branch has to be
made first. That branch will serve for tagging all releases, as well as
pointing to the latest patch release.

git switch -c v$MAJOR.$MINOR $RELEASE_HASH

If the branch already exists, check it out.

git switch v$MAJOR.$MINOR

NOTE: Do not directly commit to this branch. Follow the process and open a Pull
Request from the prep branch.

## Create a release prep branch

NOTE: Make sure this step is done from `v$MAJOR.$MINOR` branch, not `main`.

test "$(git rev-parse --abbrev-ref HEAD)" = "v$MAJOR.$MINOR" || git checkout "v$MAJOR.$MINOR"

This branch will be used to prepare all the necessary things to get ready for
release.

git switch -c release-v$MAJOR.$MINOR.$PATCH-prep

## Prepare the release notes

Using https://github.com/cilium/release, prepare the release notes between the
last minor version (latest patch) and current.

./release --repo cilium/hubble --base v$LAST_RELEASE --head v$MAJOR.$MINOR
**Bugfixes:**
* api: fix potential panic in endpoint's EqualsByID (#199, @Rolinh)

**Other Changes:**
* actions: Trigger on release branches (#233, @michi-covalent)
* Add changelog (#203, @glibsm)
* Adjust to moved PolicyMatchType location (#222, @tgraf)
* api: Small fixes to the protoc invocations in Makefile (#206, @gandro)
... etc ...

Modify `CHANGELOG.md` with the generated release notes. Keep them handy, as
the same notes will be used in the github release.

$EDITOR CHANGELOG.md
...
git add CHANGELOG.md
git commit -s -m "Modify changelog for $MAJOR.$MINOR.$PATCH release"

## Modify the version constant in the VERSION to match the new release

Usually this only consists of dropping the `-dev` suffix from the string.

Commit and push the changes to the prep branch

git add VERSION
git commit -s -m "Modify version to $MAJOR.$MINOR.$PATCH"

## Push the prep branch and open a Pull Request

The pull request has to be `v$MAJOR.$MINOR.$PATCH-prep -> v$MAJOR.$MINOR`

Once the pull request is approved and merged, a tag can be created.

## Tag a release

Identify the right commit and tag the release.

Example:

git tag -a "v$MAJOR.$MINOR.$PATCH" -m "v$MAJOR.$MINOR.$PATCH" <commit-sha>

Then push the tag.

Example:

git push origin "v$MAJOR.$MINOR.$PATCH"

## Modify the version constant on the main branch, if needed

After branching out from the tree for release, the version need to be updated
to reflect the next planned release, i.e.

VERSION="$MAJOR.<$MINOR+1>.0-dev"

## Update the changelog in the main branch

Once the release PR has been merged, copy the generated releases notes into the
CHANGELOG.md file in the `main` branch.

## Update the README.md

Update the *Releases* section of the `README.md` to point to the latest GitHub
release. This section lists all currently supported releases in a table. The
version in this table needs to be updated to match the new release.

## Update the GitHub release notes

When a tag is pushed, a Github Action job takes care of creating a new Github
draft release, building artifacts and attaching them to the draft release.

The release notes need to be manually added before manually publishing the
release.

## Update the `VERSION` file

After `v$MAJOR.$MINOR.$PATCH` is released, the next commit should restore the
`v$MAJOR.$MINOR` branch to the `v$MAJOR.$MINOR.{$PATCH+1}-dev` to separate
unreleased hubble versions in a branch from releases.

## Update the `renovate` configuration

After a new stable `v$MAJOR.$MINOR` release branch has been created, update `.github/renovate.json5`:

- Add the new branch to the `baseBranches` field and remove the previous release branch (we only maintain the most recent Hubble release). [Example](https://github.com/cilium/hubble/blob/3680a3193ac35e962bb9806c00bd481932a18725/.github/renovate.json5#L31).
- Add the new branch to the `all-go-deps-stable` packageRule in the `matchBaseBranches` field and remove the previous release branch. [Example](https://github.com/cilium/hubble/blob/3680a3193ac35e962bb9806c00bd481932a18725/.github/renovate.json5#L85-L97).
- Add the new branch to the `golang-stable` packageRule to pin the Go version used to the current minor version for the release and remove the previous release branch. [Example](https://github.com/cilium/hubble/blob/3680a3193ac35e962bb9806c00bd481932a18725/.github/renovate.json5#L127-L137).
- Add the new branch to the `alpine-stable` packageRule to pin the Alpine image version used to the current minor version for the release and remove the previous release branch. [Example](https://github.com/cilium/hubble/blob/3680a3193ac35e962bb9806c00bd481932a18725/.github/renovate.json5#L146-L155).
- Add the new branch to the `golangci-lint-stable` packageRule in the `matchBaseBranches` field and remove the previous release release branch. [Example](https://github.com/cilium/hubble/blob/3680a3193ac35e962bb9806c00bd481932a18725/.github/renovate.json5#L164-L174).

## Update the `CodeQL workflow`

After a new stable `v$MAJOR.$MINOR` release branch has been created, update
`.github/workflows/codeql-analysis.yml` to be triggered on the new branch.

## Get the Docker image build for the release approved

The
[Image Release Build workflow](https://github.com/cilium/hubble/actions/workflows/build-images-release.yaml)
needs to be approved, ping a member of the
[`hubble-maintainers` team](https://github.com/orgs/cilium/teams/hubble-maintainers) on Slack.

## Announce the release on Slack

Post a release announcement message in the [Cilium Slack #hubble
channel](https://slack.cilium.io).

Example:

 Hubble CLI v0.8.2 is released 
Release notes and binaries: https://github.com/cilium/hubble/releases/tag/v0.8.2
Notable changes:
- Change 1
- Change 2
- ...

## (OPTIONAL) Update `stable.txt` in the main branch

Hubble's installation instruction in the Cilium documentation uses the version
specified in `stable.txt` in the `main` branch. There are a couple of things to
consider when deciding whether to update `stable.txt`. Let's say `stable.txt`
is currently pointing to `v0.6.1`:

- If this is a minor or patch release relative to the current stable version (i.e. `v0.7.0`
or `v0.6.2`), update `stable.txt` so that people start picking up the new features / bug
fixes included in this release.
- If this is a patch release of a previous version (e.g. `v0.5.2`), don't update
`stable.txt`.
- If this is a major release (e.g. `v1.0.0`), the installation instructions in older Cilium
documentation versions need to be updated to point to a compatible version of Hubble. Then,
ensure the version specified in `stable.txt` is compatible with the current stable Cilium
version.

To update `stable.txt`, do:

git switch -c update-stable-txt main
echo v$MAJOR.$MINOR.$PATCH > stable.txt
git add stable.txt
git commit -as -m "Point stable.txt to $MAJOR.$MINOR.$PATCH"
git push

and then open a pull request against the `main` branch.

## (OPTIONAL) Update the Homebrew formula

The Homebrew formula for Hubble can be updated using the command:

brew bump-formula-pr --version=$MAJOR.$MINOR.$PATCH hubble

This will automatically create a PR against https://github.com/Homebrew/homebrew-core
bumping the version. This assumes a GitHub access token exported in
`$HOMEBREW_GITHUB_API_TOKEN`, see `brew bump-formula-pr --help` for details.
[the release issue template]: https://github.com/cilium/hubble/issues/new?template=release.md

0 comments on commit e2230fd

Please sign in to comment.