Use trusted publishing for crates.io (#18709)

Moves from a crates.io API key to trusted publishing.

Setup of trusted publishing is automated via a script which creates the
trust relationship and disables publish by API key. The main breakage
here is that now, when we add a new crate, a release will fail. The
script is invoked during `release.sh` to catch this case and supports
creating a stub crate so the release can subsequently succeed — but this
will require the release author to have a local crates.io API key with
permissions to create projects and configure publishing. I tested this
script a few times end-to-end, but would not be surprised if it bites us
in the future.
This commit is contained in:
Zanie Blue
2026-03-25 09:15:44 -05:00
committed by GitHub
parent 8cdb2b087a
commit edc1beb69a
6 changed files with 596 additions and 4 deletions
+4 -4
View File
@@ -20,15 +20,15 @@ jobs:
deployment: false
permissions:
contents: read
id-token: write
steps:
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
with:
persist-credentials: false
# TODO(zanieb): Switch to trusted publishing once published
# - uses: rust-lang/crates-io-auth-action@v1
# id: auth
- uses: rust-lang/crates-io-auth-action@bbd81622f20ce9e2dd9622e3218b975523e45bbe # v1.0.4
id: auth
- name: Publish workspace crates
# Note `--no-verify` is safe because we do a publish dry-run elsewhere in CI
run: cargo publish --workspace --no-verify
env:
CARGO_REGISTRY_TOKEN: ${{ secrets.CRATES_TOKEN }}
CARGO_REGISTRY_TOKEN: ${{ steps.auth.outputs.token }}
+1
View File
@@ -273,6 +273,7 @@ jobs:
# publish jobs get escalated permissions
permissions:
"contents": "read"
"id-token": "write"
# Create a GitHub Release while uploading all files to it
announce: