-
Notifications
You must be signed in to change notification settings - Fork 254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci: add release pipeline #466
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
I was planning to tag v1.17 and v1.18 releases today. Should we test this out?
next_version=${{ steps.parse_info.outputs.next_version }} | ||
|
||
git checkout -b version-bump-$next_version | ||
./scripts/increment-cargo-version.sh patch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll need to modify the PR to revert the hashbrown and proc-macro2 version changes.
I think we can get rid of that problem by bumping the hashbrown version. I'll create an issue for that one today.
id: parse_info | ||
run: | | ||
# get the next version | ||
version=${{ github.ref_name }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if it will work here, but scripts/confirm-cargo-version-numbers-before-bump.sh was written to confirm some assumptions that should be true here.
Backports to the stable branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. |
Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis. |
(cherry picked from commit 212cbdb)
(cherry picked from commit 212cbdb)
) ci: add release pipeline (anza-xyz#466) (cherry picked from commit 212cbdb) Co-authored-by: Yihau Chen <a122092487@gmail.com>
Problem
we should have an automatic release pipeline. this PR is the first step. it will be triggered by a pushing tag. when it becomes stable, I will push another PR for pushing tag weekly!
Summary of Changes
add 3 different jobs in this release pipeline
trigger-buildkite-pipeline
this one will trigger secondary pipeline on buildkite instead of webhook. It will ensure all secondary pipelines are executed successfully.
image
draft-release
create a draft release for binaries.
image
version-bump
create a version bump PR automatically.
image
Before Merge
TRIGGER_BK_BUILD_TOKEN
to Github Actions