fix(ci): let the crates.io publish bootstrap a crate that does not exist yet - #5
Merged
Merged
Conversation
…ist yet The v1.2.1 release failed to publish deckfile: Status: 400. No Trusted Publishing config found for repository `spacedevin/deck`. Trusted Publishing config is attached to a crate you already own, so it cannot publish a crate that has never been published — there is nothing to attach the config to. The workflow only had that path, so the very first publish, the one that claims the name, was the one case it could not do. Adds a CARGO_REGISTRY_TOKEN fallback used only to bootstrap: set the secret, release once to claim `deckfile`, configure Trusted Publishing, then delete the secret and this reverts to OIDC on its own. The long-lived token exists only for as long as the bootstrap takes, which keeps the steady state the same as npm-release.yml's. The token presence is detected in a step that reads it through `env` and writes an output, because the `secrets` context is not available in a step-level `if` — gating directly on `secrets.CARGO_REGISTRY_TOKEN` there would have silently evaluated empty and always taken the OIDC path. Also fails with an actionable message naming both options rather than whatever cargo says about a missing credential.
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.
What happened
v1.2.1 promoted cleanly and
@spacedevin/deck@1.2.1reached npm, but the crate publish failed:Trusted Publishing config is attached to a crate you already own, so it can't publish a crate that has never been published — there's nothing to attach the config to. The workflow only had that path, which means the one publish it couldn't do was the first one: the one that claims the name.
Everything up to auth worked, so this is the only thing between here and
deckfileexisting:Fix
A
CARGO_REGISTRY_TOKENfallback, used only to bootstrap:CARGO_REGISTRY_TOKENas a repo secretdeckfiledeckfile→ Settings → Trusted Publishing → ownerspacedevin, repodeck, workflowcrates-release.yml)So the long-lived token exists only for as long as the bootstrap takes, and the steady state matches
npm-release.yml: OIDC, no stored token.One subtlety worth calling out
The token check can't be written the obvious way. The
secretscontext is not available in a step-levelif— only inenv. Gating directly onsecrets.CARGO_REGISTRY_TOKEN == ''would have silently evaluated as empty and always taken the OIDC path, i.e. it would have looked correct and never worked. So presence is detected in a step that reads the secret throughenvand writes a step output, which theifthen gates on.Also fails with a message naming both options, instead of whatever cargo reports about a missing credential.
Note
Trusted Publishing is now the steady-state path, not the only one — worth knowing if you'd rather just keep the token, though deleting it after bootstrap is the stronger posture.