Repository navigation
Publish to crates.io when a version tag is pushed - #13
Merged
Merged
Conversation
release-crates.yml was a manual dispatch that published one crate at a time, so the order (sigit-si-api first) was left to the person running it. It now runs on a v*.*.* tag, checks that the crate versions match the tag, runs the workspace tests, and publishes whichever of sigit-si-api and sigit-si-cli is missing from crates.io, in that order. It keeps Trusted Publishing, so no token is stored. Once that finishes it dispatches release-mcp-registry.yml. workflow_dispatch stays for re-runs, with a tag input and a dry_run switch that skips the token, the upload and the dispatch. The README gets a short paragraph on how to cut a release. Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
![sigit-code-review[bot]](https://avatars.githubusercontent.com/in/3492899?s=60&v=4){kind=small}
There was a problem hiding this comment.
This change automates crate publishing on a version tag push. The workflow now checks that all crates under crates/ match the tag version, runs tests, checks crates.io for existing versions, and publishes sigit-si-api and sigit-si-cli in order if needed. It uses Trusted Publishing and queues duplicate runs for the same tag. The README now documents the release process. The workflow also always dispatches the MCP registry release, regardless of whether new crates were published. Previous manual steps and single-crate dispatch are replaced by this automated, version-tag-driven flow.
Automated review by siGit Code Review · commit 2d6828b · see the review dashboard
paydii
approved these changes
Oct 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Releasing 1.3.0 today means dispatching
release-crates.ymlby hand once per crate and remembering thatsigit-si-apigoes first. This makes the tag do it, the way the sibling repos work.sigit-si-clialso never got its 1.2.0 on crates.io, so the old flow already let one slip.On a
v*.*.*tag the workflow:crates/is at the tag's version, and fails naming the ones that aren'tcargo test --workspace --lockedsigit-si-apiandsigit-si-cliare already published at that version, and publishes whichever is missing, API first (cargo publishwaits for the index, so no sleep)release-mcp-registry.ymlat the tag, even when nothing new was published, since that workflow skips duplicates itselfPublishing still uses Trusted Publishing, so there's no stored token.
workflow_dispatchstays for re-runs, with ataginput and adry_runswitch that skips the token, the upload and the dispatch. Runs for the same tag queue instead of cancelling.The README has a short paragraph on how to cut a release.
Checked locally:
actionlintis clean. The version check passes against 1.3.0 and fails for a 1.2.0 tag, naming both crates. The crates.io check returns 200 forsigit-si-api1.2.0 and 404 for 1.3.0.cargo publish --dry-run --locked -p sigit-si-apipackages fine. The CLI dry run can't resolvesigit-si-api1.3.0 until it's published, which is why the order matters.Both crates have a Trusted Publisher entry for
getsigit/siandrelease-crates.yml. This PR doesn't tag or publish anything. After it merges, 1.3.0 goes out by mergingdevelopmentintomainand pushingv1.3.0.