-
Notifications
You must be signed in to change notification settings - Fork 320
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: workflow for publishing crates #5105
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.
Added some in-line comments to guide review.
publish: | ||
runs-on: buildjet-16vcpu-ubuntu-2204 | ||
env: | ||
CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_REGISTRY_TOKEN }} |
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.
Added this in the repo settings.
|
||
# Publish the workspace to crates.io. | ||
- name: publish crates | ||
run: nix develop --command ./deployments/scripts/publish-crates |
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.
This script is already in place, and precisely what I've been using locally to handle publication when a new tag is cut.
|
||
# The `rust-toolchain.toml` file dictates which version of rust to setup. | ||
- name: check rust version | ||
run: nix develop --command rustc --version |
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.
Reusing the nix env simply to pull in relevant tooling like cargo-release
, so it's pinned to the same version I use locally.
Describe your changes
Adds a simple workflow to handle publishing the workspace's crates to crates.io. Will run whenever a new tag is pushed to the repo, and publish the crates under that tag.
Issue ticket number and link
Closes #5005. Refs #5104, #4978.
Testing and review
I've been handling the publication step manually, locally, after tagging release, to ensure that the script is stable enough to stick in automation. It's been well behaved for the past few minor releases, so let's try it out in automation. I'll handle verifying behavior post-merge, post-release.
Checklist before requesting a review
I have added guiding text to explain how a reviewer should test these changes.
If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: