Repository navigation
Make the crates publishable, and document where the token goes - #4
Merged
Merged
Conversation
cargo install bootintel-cli was impossible for two reasons that had nothing to do with credentials, so handing over a token alone would not have worked. crates/cli carried publish = false, with a comment explaining it existed to satisfy cargo-deny's wildcard-dep check because bootintel-detectors was declared as a bare path dependency. The actual fix is to give that dependency both a path and a version: cargo uses the path locally and the version when packaging. Verified that cargo deny still reports advisories, bans, licenses and sources all ok afterwards, so the workaround is no longer earning its keep. The ordering is not optional and is easy to get wrong once: the library must be on the index before the binary crate can be packaged, otherwise cargo fails with "no matching package named bootintel-detectors". Reproduced here. The new publish-crates job does them in order and waits for the index to become consistent in between. The job is opt-in behind a publish_crates dispatch input and refuses to start without CARGO_REGISTRY_TOKEN, with an error naming the exact settings page. That check exists because the failure it prevents is unrecoverable: a crates.io version can be yanked but never reused, so a half-publish would burn 0.4.0 permanently. docs/releasing.md records the whole process, including the token scopes and the reason the Homebrew line must not be advertised before the tap exists. No install claim was added that does not work yet, which is the mistake that made three advertised channels dead ends in the first place. Also refreshed four stale cli-v0.3.1 references in the README, including the GitHub Action pin and the attestation-verify example. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merged
Zenofex
added a commit
that referenced
this pull request
Sep 26, 2026
Makes the published crate match its tag. The publishability fix (#4) landed after `cli-v0.4.0` was already tagged and released. Publishing under 0.4.0 would have put a crate on crates.io whose contents differed from the tag and the release archives, and since a crates.io version can be yanked but never reused, that divergence would be permanent. 0.4.1 is the first version where the tag, the binaries and the crate are all the same code. No user-visible behaviour change, so PATCH per the policy in CHANGELOG.md. One detail worth flagging: the version pin on the `bootintel-detectors` path dependency has to track the workspace version. Bumping only the workspace would leave `crates/cli` asking the index for 0.4.0 while publishing 0.4.1. Verified locally: 274 tests pass, `cargo deny check` reports advisories, bans, licenses and sources all ok, rustfmt clean, and `cargo package -p bootintel-detectors` succeeds. After merge: dispatch `cli-release` with version `0.4.1` and `publish_crates` checked. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
cargo install bootintel-cliwas blocked by two things that are not credentials, so a token alone would not have worked.publish = false. It was oncrates/clito satisfy cargo-deny's wildcard-dep check, becausebootintel-detectorswas a bare path dependency. The real fix is to give that dep both a path and a version: cargo uses the path locally and the version when packaging.cargo deny checkstill reports advisories, bans, licenses and sources all ok.Publish order. The library must be on the index before the binary crate can be packaged. Reproduced:
cargo package -p bootintel-clifails withno matching package named bootintel-detectors. The newpublish-cratesjob publishes the library, waits for index consistency, then publishes the binary crate.The token. Opt-in behind a
publish_cratesdispatch input, and the job refuses to start withoutCARGO_REGISTRY_TOKEN, pointing at the exact settings page. That guard matters because the failure is unrecoverable: a crates.io version can be yanked but never reused, so a half-publish would burn 0.4.0 for good.docs/releasing.mddocuments the process, token scopes, and why the Homebrew line stays unadvertised until the tap exists. No install claim was added that does not work yet, which is the mistake that left three advertised channels as dead ends.Also refreshed four stale
cli-v0.3.1references in the README.