Skip to content

Commit

Permalink
Automate edge releases (#12175)
Browse files Browse the repository at this point in the history 
* Automate edge releases

Followup to #12132

Now one only needs to tag in order to trigger the release. Please see the updated `RELEASE.md` file for the new instructions.

The last action in the release workflow, `helm-publish`, now runs:

- `bin/helm-bump-edge`: This has been modified to calculate the new edge version by inspecting https://run.linkerd.io/install-edge and bumping the version found there, using a new scheme `YYYY.M.N` (also droppping the `-edge` suffix) shared across all the charts (except for `partials`, `patch` and `linkerd-multicluster-link` which remain static). The `version` entry in the Chart.yaml files no longer needs to be manually updated, and its value is not used for the new version computation, so it was changed to `0.0.0-undefined`. Also note this script validates that the current git tag matches the expected new version.
- `bin/helm-docs`: Called just to update the charts READMEs with the new version. We also still call it in the `helm.yml` workflow to check the values.yaml entries are in sync. So after any change to those values, we still need to manually run `bin/helm-docs`.
- `bin/helm-build package`: As the previous two steps mutate the local checked out source, this no longer validates that there are no uncommited changes.

---------

Co-authored-by: Oliver Gould <[email protected]>
  • Loading branch information
@alpeb @olix0r
alpeb and olix0r authored Mar 1, 2024
1 parent 3d331d7 commit c2eb296
Show file tree
Hide file tree
Showing 19 changed files with 87 additions and 386 deletions.
12 changes: 5 additions & 7 deletions .github/actions/helm-publish/action.yml
View file
Original file line number Diff line number Diff line change
@@ -1,9 +1,5 @@
name: Helm publish
description: Helm chart creation and uploading
inputs:
branch:
description: edge | stable
required: true
runs:
using: composite
steps:
Expand All @@ -12,7 +8,9 @@ runs:
- shell: bash
run: |
mkdir -p target/helm
gsutil cp gs://helm.linkerd.io/${{ inputs.branch }}/index.yaml target/helm/index-pre.yaml
gsutil cp gs://helm.linkerd.io/edge/index.yaml target/helm/index-pre.yaml
bin/helm-bump-edge
bin/helm-docs
bin/helm-build package
cp charts/artifacthub-repo-${{ inputs.branch }}.yml target/helm/artifacthub-repo.yml
gsutil rsync target/helm gs://helm.linkerd.io/${{ inputs.branch }}
cp charts/artifacthub-repo-edge.yml target/helm/artifacthub-repo.yml
gsutil rsync target/helm gs://helm.linkerd.io/edge
10 changes: 0 additions & 10 deletions .github/workflows/release.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,6 @@ on:
push:
tags:
- "edge-*"
- "stable-*"

permissions:
contents: read
Expand Down Expand Up @@ -226,7 +225,6 @@ jobs:
- integration_tests
# TODO(ver) choco packages are not produced for edge releases...
# - choco_pack
if: startsWith(github.ref, 'refs/tags/stable') || startsWith(github.ref, 'refs/tags/edge')
timeout-minutes: 30
runs-on: ubuntu-20.04
permissions:
Expand Down Expand Up @@ -314,12 +312,4 @@ jobs:
with:
credentials_json: ${{ secrets.LINKERD_SITE_TOKEN }}
- name: Edge Helm chart creation and upload
if: startsWith(github.ref, 'refs/tags/edge')
uses: ./.github/actions/helm-publish
with:
branch: edge
- name: Stable Helm chart creation and upload
if: startsWith(github.ref, 'refs/tags/stable')
uses: ./.github/actions/helm-publish
with:
branch: stable
236 changes: 16 additions & 220 deletions RELEASE.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -49,162 +49,15 @@ Create a new branch in the `linkerd2` repo,

Open a pull request that includes the changes.

## 3. Create a minor releases branch
## 3. Optional: push images

**This step only applies to minor stable releases (e.g. `2.9.1`).**

If it doesn't exist yet, create and push a branch in the `linkerd2` repo where
all the minor releases for a given major release will reside:

```bash
git checkout -b release/2.9
git push -u origin release/2.9
```

The branch in the following step should be based off of this one.

## 4. Create the release branch

Create a branch in the `linkerd2` repo, `username/edge-X.X.X` (replace with
your name and the actual release number, optionally replace `edge` with
`stable`).

## 5. Cherry pick changes from `main`

**This step only applies to minor stable releases (e.g. `2.9.1`).**

Locate all the commits in the git log that happened since the last stable
release, that you'd like to include in the current minor stable release, and
cherry-pick each one into the current branch using their corresponding SHAs:

```bash
git cherry-pick ae34bcc2
git cherry-pick b34effab
git cherry-pick 223bd232
...
```

Each step might result in conflicts that you'll need to address.

## 6. Update the Helm charts versions

All the Helm charts (linkerd-crds, linkerd-control-plane, linkerd2-cni,
linkerd-multicluster, linkerd-jaeger and linkerd-viz) have a `version` entry
with a semver format `major.minor.patch[-edge]` that needs to be updated
according to the rules below.

Note that the `appVersion` entry (for those charts that have it) is handled
automatically by CI.

Also keep in mind chart version changes require updating the charts README
files (through `bin/helm-docs`) and golden files (through `go test ./...
-update`).

Example:

```text
Stable release:
1.9.0
Subsequent edges:
1.10.0-edge
1.10.1-edge
Stable maintenance release:
1.9.1
Subsequent edges:
1.10.2-edge
1.10.3-edge
Stable release:
1.11.0
Subsequent edges:
1.12.0-edge
1.12.1-edge
```

### Edge releases

When making the first edge release right after a stable one, bump the minor and
reset the patch. This leaves room for eventual maintenance stable release
versions.

MOST COMMON CASE: If making an edge release after another edge release, just
bump the patch.

In any case remember to keep the `-edge` suffix.

### Stable releases

When making a new stable release off of `main` (new major `2.x.0` release):

- reset patch
- If there are breaking changes, most notably changes to the structure of
`values.yaml`: bump major and reset minor
- If the changes are non-breaking: bump minor (with respect to previous edge)
- remove the `-edge` suffix

When making a stable maintenance release off of a `release/stable-2.x` branch
(new `2.x.y` release), just bump the minor.

In any case remember to remove the `-edge` suffix.

### linkerd-crds

Almost all the charts are always updated, at least because the docker image
versions referred in their templates change with each release. One exception is
`linkerd-crds`, which doesn't contain image references. So this chart only
requires bumping its `version` if there were changes in its templates files.

## 7. Update the release notes

On this branch, add the release notes for this version in `CHANGES.md`.

Please include links/references to publicly reported bugs which are fixed by
this release. The fix needs to be referenced whenever it is introduced into
the corresponding release channel (edge or stable).

Note: To see all of the changes since the previous release, run the command
below in the `linkerd2` repo. If the last release was a stable release, be
sure to use `stable-Y.Y.Y` instead of `edge-Y.Y.Y`.

```bash
git log edge-Y.Y.Y..HEAD
```

And this command in the `linkerd2-proxy` repo:

```bash
git log release/vX.X.X..release/vY.Y.Y
```

Where `release/vX.X.X` is the version of the proxy from the last release
and `release/vY.Y.Y` is the version of the proxy for this release, e.g.:

```bash
git log release/v2.102.0..release/v2.103.0
```

## 8. Post a PR that includes the changes

If you're preparing a minor release, make sure the PR's merge target is the
releases branch you created above (e.g. `releases/stable-2.9`). For the other
cases the target should just be `main`.

This PR needs an approval from a "code owner." Feel free to ping one of the
code owners if you've gotten feedback and approvals from other team members.

## 9. Optional: push images

To facilitate testing (particularly for stable releases) you might want to
publish the docker images in your private repo.
To facilitate testing you might want to publish the docker images to your
private repo.

First tag the release:

```bash
git tag stable-2.9.1
git tag edge-2024.3.1
```

Do *not* push this tag just yet, to avoid triggering the actual public release.
Expand Down Expand Up @@ -237,54 +90,23 @@ it again and push it for good as explained in the following step.
Now testers can pull the CLI binaries through this:

```bash
DOCKER_REGISTRY=ghcr.io/$GH_USERNAME bin/docker-pull-binaries stable-2.9.1
DOCKER_REGISTRY=ghcr.io/$GH_USERNAME bin/docker-pull-binaries edge-2024.3.1
```

which will dump them under the `target/release` directory.

Besides using those particular binaries to install Linkerd, they'll also need to
point to your registry using the `--registry` flag. Currently that flag doesn't
apply to add-ons, so you need to also recur to the `--config` flag. Currently
that only applies to Grafana:

```bash
$ cat linkerd-overrides.yml
grafana:
enabled: true
image:
name: ghcr.io/alpeb/grafana

$ target/release/linkerd2-cli-stable-2.9.1-darwin install --registry ghcr.io/$GH_USERNAME --config ~/tmp/linkerd-overrides.yml
```

## 10. Merge release notes branch, then create the release tag

After the review has passed and the branches from step 2 and 4 have been merged,
follow the instructions below to properly create and push the release tag from
the appropriate branch.

**Note**: The release script will create a GPG-signed tag, so users must have
GPG signing setup in their local git config.

If performing an edge release then issue these commands. The appropriate tag
will be automatically calculated:
point to your registry using the `--registry` flag.

```bash
git checkout main
git pull
./bin/create-release-tag edge
target/release/linkerd2-cli-edge-2024.3.1-darwin install --registry ghcr.io/$GH_USERNAME -f ~/tmp/linkerd-overrides.yml
```

If performing a stable release then issue these commands instead (in this case
you need to explicitly pass the version to be released):
## 4. Tag the release

```bash
git checkout main
git pull
./bin/create-release-tag stable x.x.x
```

In both cases follow the instructions on screen for pushing the tag upstream.
- Checkout the `main` branch
- Tag, e.g. `edge-24.3.1`
- Push the tag

That will kick off a CI Release workflow run that will:

Expand All @@ -293,14 +115,14 @@ That will kick off a CI Release workflow run that will:
- Run a k3d integration test on a separate ARM64 host
- Create a release in Github, and upload the CLI binaries with their checksums
- Dispatch an event caught by the website repo that triggers a website rebuild
which will update the edge/stable versions in the website
which will update the edge version in the website
- Retrieve the installation script from [run.linkerd.io](https://run.linkerd.io)
and verify it installs the current version being released
- Deploy the updated helm charts

You can locate the CI run [here](https://github.com/linkerd/linkerd2/actions).

## 11. Do a walkthrough verification of the release
## 5. Do a walkthrough verification of the release

Go to the release page in Github and check that the notes are properly
formatted and the files are there. Download the file for your system along
Expand All @@ -315,13 +137,7 @@ linkerd viz check
linkerd dashboard
```

- Install linkerd onto your cluster, and run a few CLI commands
- Open the dashboard and click around
- Click through to Grafana
- When finished with this step, you may want to delete your `alias` to prevent
confusion later

## 12. Send the announcement email
## 6. Send the announcement email

Send an email to <[email protected]>,
<[email protected]>, and <[email protected]>,
Expand All @@ -333,8 +149,7 @@ Subscribe to these mailing lists if you aren't on them:
- [linkerd-announce](https://lists.cncf.io/g/cncf-linkerd-announce/join)
- [linkerd-dev](https://lists.cncf.io/g/cncf-linkerd-dev/join)

Make sure to include the install instructions (adjust depending if it's an edge
or a stable release):
Make sure to include the install instructions.

> To install the CLI for this edge release, run:
<!-- markdownlint-disable MD034 -->
Expand All @@ -347,26 +162,7 @@ to upgrade your cluster using either the CLI or Helm.

Aftewards, include the full release notes. Liberally apply emoji. ⭐

## 13. Send an announcement to Linkerd Slack's #announcements channel
## 7. Send an announcement to Linkerd Slack's #announcements channel

Ensure that you send a brief summary of the release in Linkerd Slack's
[#announcement](https://linkerd.slack.com/messages/C0JV5E7BR) channel.

## 14. Add a community page announcement to the website repo

When doing a `stable-X.X.X` be sure to also include an announcement page for
the Linkerd2 dashboard "Community" sidebar button.

In the [website](https://github.com/linkerd/website) repo:

1. Run `hugo new --contentDir linkerd.io/content/dashboard/ YYYYMMDD.md`
2. Open the newly created file in your favorite editor and change the `title`
to match the announcement email title.
3. Remove the `draft: true` section in the file and then add a brief summary
of the stable release.
4. cd to the directory `linkerd.io`.
5. Run `hugo serve` in the directory to test your changes.
6. Verify your change by navigating to `http://localhost:1313/dashboard`. Make
sure that the announcement appears at the top of the page.
7. Once you are satisfied with your changes, Post the PR for review.
Once merged, the change should deploy automatically.
Loading

0 comments on commit c2eb296

Please sign in to comment.