build(release): add release workflow #2829
Conversation
hairyhum
force-pushed
the
ci-release
branch
29 times, most recently
from
8c8c8ed
to
b5540aa
Compare
Release workflow will: - Create and push a release tag - Produce release using goreleaser with binaries and helm charts, this does not build example images - Build docs from docs_new - Publish docs and helm charts index in the github pages - Separately build example images for the tag
RELEASE.md
Outdated
| Release process: | ||
|
|
||
| - Verify the release version by looking at the [releases page](https://github.com/kanisterio/kanister/releases) on the Kanister repo. | ||
| - Trigger the [pre-release](#pre-release-workflow) workflow with the desired version number (e.g. bump the minor version portion 0.106.0 -> 0.107.0) |
There was a problem hiding this comment.
| - Trigger the [pre-release](#pre-release-workflow) workflow with the desired version number (e.g. bump the minor version portion 0.106.0 -> 0.107.0) | |
| - Trigger the [pre-release](#pre-release-workflow) workflow with the desired version number (e.g. bump the minor version portion 0.106.0 -> 0.107.0), which will result in a PR getting created in Kanister repo |
RELEASE.md
Outdated
| - The Kanister release job will publish a new tag, update documentation, build all the docker images, and push them to the [ghcr.io](https://github.com/orgs/kanisterio/packages) registry. | ||
| - Once the job is complete, a Slack notification will be sent to the kanister channel. |
There was a problem hiding this comment.
Other points don't have full stop at the end, these two points have.
Also, we have not implemented the slack notification yet, should be just remove this point or strikethrough it?
RELEASE.md
Outdated
|
|
||
| ### Pre-release workflow | ||
|
|
||
| `pre-release` workflow serves to create a new version of kanister, it updates version number and creates a PR in kanister repo. |
There was a problem hiding this comment.
| `pre-release` workflow serves to create a new version of kanister, it updates version number and creates a PR in kanister repo. | |
| `pre-release` workflow serves to create a new version of kanister, and updates the older version number in source files of kanister repo with new version and creates a PR in kanister repo. |
|
|
||
| - Verify if the docker [images](https://github.com/orgs/kanisterio/packages?repo_name=kanister) have a new tag. NOTE: Not all docker images are relevant. | ||
| TODO: Add a list of the most relevant docker images to be verified here. | ||
|
|
There was a problem hiding this comment.
Should we add another point here about updating the helm repo and checking that new version of chart is updated?
| If pre-release pipeline does not work. | ||
|
|
||
| ``` | ||
| $ export PREV_TAG="0.42.0" |
There was a problem hiding this comment.
If I didn't misread things, when the pre-release happens using actions we documented above that we are supposed to give the new version that we want to release kanister with. For example if the latest tag in kanister repo is 0.101.0 we are supposed to give 0.102.0.
But here we are saying we have to give the previous tag? If that is the case, it might be confusing.
There was a problem hiding this comment.
Added clarification
|
Test run can be found here: https://github.com/kanisterio/kanister/actions/runs/9699450217 Note that changelog is missing because release notes are note present in the repo ATM |
| ${{ inputs.extra_tags }} | ||
| labels: ${{ inputs.labels }} | ||
| - name: Build and push | ||
| uses: docker/build-push-action@v5 |
There was a problem hiding this comment.
@hairyhum Please pin the version for this action using its digest. For an example, see how the action is specified in the previous step.
The OSSF workflow also checks for this, as it considers it a good practice.
| export HELM_RELEASE_REPO_INDEX=https://charts.kanister.io/ | ||
| make package-helm VERSION=${RELEASE_TAG} | ||
| - name: Free Disk Space (Ubuntu) | ||
| uses: jlumbroso/free-disk-space@main |
There was a problem hiding this comment.
Please tag this action's version. It should not use a "floating" tag or repo branch name.
| GHCR_LOGIN_USER: ${{ github.actor }} | ||
| GORELEASE_PARAMS: ${{ env.DRAFT_RELEASE == 'true' && '--draft' || '' }} | ||
| ## Upload to use in docs publishing | ||
| - uses: actions/upload-artifact@v4 |
| package_json_file: docs_new/package.json | ||
| version: 8 | ||
| - name: Setup Node | ||
| uses: actions/setup-node@v4 |
| with: | ||
| ref: ${{ env.RELEASE_TAG }} | ||
| - name: Setup pnpm | ||
| uses: pnpm/action-setup@v3 |
| with: | ||
| node-version: 20 | ||
| - name: Setup Pages | ||
| uses: actions/configure-pages@v4 |
| run: pnpm docs:build | ||
| working-directory: ./docs_new | ||
| - name: download helm index | ||
| uses: actions/download-artifact@v4 |
| name: helm-index | ||
| path: docs_new/.vitepress/dist/helm_charts/ | ||
| - name: Upload artifact | ||
| uses: actions/upload-pages-artifact@v3 |
Change Overview
Release workflow will:
Main changes
pre-release: Update version to ...format for merge commits of PRs like pre-release: Update version to 0.0.0 #2814workflow_dispatchif we wantx.x.x-rc1. Mostly for test purposes. Those will be created as pre-releases in the github.Changes in helm chart publishing
Helm charts are now published as release artifacts. Helm chart index is published in the github pages together with docs (just in a separate directory).
Helm chart index source is still taken from charts.kanister.io, so before we change the DNS it will include references to the old charts in S3.
For some time I believe we will be publishing to both S3 and github release/github pages.
Pull request type
Please check the type of change your PR introduces:
Test Plan
Test release
There is a
ci-release-testbranch which can be used to create test releases.One way to do that is to run workflow dispatch:
Another is to push a commit with the pre-release message format:
pre-release: Update version to 0.107.0-rc2 (placeholder)(don't forget the placeholder, merge commits have the PR reference there)This will create a tag, build images and publish a draft release on github. You can track the progress in https://github.com/kanisterio/kanister/actions/workflows/release.yaml
If tag already exists in github, the workflow will fail, so please use new tags when testing.
Example runs:
Workflow dispatch: https://github.com/kanisterio/kanister/actions/runs/8791390369
Push: https://github.com/kanisterio/kanister/actions/runs/8791400326
💪 Manual
⚡ Unit test
💚 E2E