Repository navigation
ci: publish to crates.io via trusted publishing - #14
Conversation
Add release-crates.yml, which runs `cargo publish --locked` when a v* tag is pushed, using the CARGO_REGISTRY_TOKEN secret. Also add the release skill documenting the version-bump checklist, the fmt/clippy/test gate, fast-forwarding main, tagging, and verifying the published GitHub release and crate. Co-Authored-By: SplitFire v1.1.1-acp <noreply@splitfire.ai>
![sigit-code-review[bot]](https://avatars.githubusercontent.com/in/3492899?s=60&v=4){kind=small}
There was a problem hiding this comment.
Adds a new GitHub Actions workflow release-crates.yml that triggers on v* tags and publishes the crate to crates.io using cargo publish --locked with the CARGO_REGISTRY_TOKEN secret. Also adds a detailed release skill document SKILL.md describing the full release process, including version bump checks, CI gate commands, fast-forwarding main, tagging, and verification steps. This complements the existing release workflow that builds binaries and creates GitHub releases, automating crate publishing and documenting the process clearly.
Automated review by siGit Code Review · commit 7ef4f8d · see the review dashboard
Swap the CARGO_REGISTRY_TOKEN secret for crates.io trusted publishing: the job requests an OIDC token (permissions: id-token: write), rust-lang/crates-io-auth-action exchanges it for a short-lived crates.io token, and cargo publish --locked consumes it. The action revokes the token in its post step, so there is no long-lived credential in repo secrets. The action is pinned to v1.0.5 rather than the v1 the crates.io docs show, because that repo publishes no moving v1 tag and @v1 fails to resolve. Document the one-time crates.io-side setup in the release skill: a trusted publisher must name SplitFireAI / splitfire-agent / release-crates.yml, and the workflow filename is part of the trust claim. Co-Authored-By: SplitFire v1.1.1-acp <noreply@splitfire.ai>
There was a problem hiding this comment.
This change introduces a new workflow, .github/workflows/release-crates.yml, which publishes the crate to crates.io on v* tag pushes using trusted publishing via OIDC and the crates-io-auth-action. The accompanying skill documentation, .agents/skills/release/SKILL.md, provides a detailed, step-by-step release runbook, including version bumping, CI gate, tagging, and verification of both GitHub and crates.io releases. The documentation is thorough and matches the workflow implementation. The earlier finding about the need for the CARGO_REGISTRY_TOKEN secret is now addressed by trusted publishing, which does not require a long-lived secret, but does require the trusted publisher to be configured on crates.io for this workflow filename. No source code is changed, only CI and documentation are added. The workflow is safe, but will fail if the trusted publisher is not configured or if the version is already published on crates.io.
Automated review by siGit Code Review · commit cf210b4 · see the review dashboard
setoelkahfi
changed the title
What
Adds a second release workflow plus the skill that documents the release process.
.github/workflows/release-crates.yml— on av*tag push, publishes the crate to crates.io using trusted publishing. The job requests an OIDC token (permissions: id-token: write),rust-lang/crates-io-auth-actionexchanges it for a short-lived crates.io token, andcargo publish --lockedconsumes it. The action revokes the token in its post step..agents/skills/release/SKILL.md— the end-to-end release runbook: the one-time trusted-publisher setup, version-bump checklist (Cargo.toml/Cargo.lock/registry/agent.jsonmust agree), the exact CI gate (fmt/clippy -D warnings/test), fast-forwardingmain, the annotated tag, and verifying the published release and crate.Why
Tagging currently publishes binaries but leaves the crate publish as a manual
cargo publishon the maintainer's machine. Trusted publishing closes that gap without introducing a long-lived credential: noCARGO_REGISTRY_TOKENsecret to store, rotate, or leak, and the token is scoped to a single job and expires in 30 minutes.Since crates.io is immutable — a version can be published once, then only yanked, never replaced — the runbook also makes the "bump before you tag" ordering explicit rather than tribal knowledge.
One-time setup required before the first tagged run
Trusted publishing needs a publisher registered on crates.io. It cannot be configured from CI:
crate page → Settings → Trusted Publishing → Add → GitHub:
SplitFireAIsplitfire-agentrelease-crates.yml(bare filename, no path)The crate is already on crates.io (
1.2.0), and a first-ever publish would still need a manual token — both prerequisites are satisfied. The workflow filename is part of the trust claim, so renaming the workflow breaks publishing until crates.io is updated to match.Notes for review
v1.0.5, not@v1. The crates.io docs example shows@v1, butrust-lang/crates-io-auth-actionpublishes no movingv1tag — onlyv1.0.0–v1.0.5— so@v1fails to resolve. Verified viagit ls-remoteand the REST refs API. Worth revisiting if a moving tag appears.actions/checkout@v5matches the existing workflows (the docs example uses@v6).cargo publish --lockedis intentionally notcontinue-on-error: a failed publish should surface loudly.main(previous tags are plain annotated, messageRelease vX.Y.Z), which is unchanged by this PR.Test plan
cargo fmt -- --checkcargo clippy --locked --all-targets -- -D warningscargo test --lockedv*-versioned commit:cargo publish --locked --dry-runrelease-cratesjob authenticates and publishes, alongside the five-targetreleasejobNo source changes, so the matrix should be quick.