Skip to content

fix(ci): add a workflow to yank a bad crates.io version - #8

Merged
spacedevin merged 1 commit into
mainfrom
chore/crates-yank-workflow
Aug 3, 2026
Merged

fix(ci): add a workflow to yank a bad crates.io version#8
spacedevin merged 1 commit into
mainfrom
chore/crates-yank-workflow

Conversation

@spacedevin

Copy link
Copy Markdown
Owner

deckfile 1.2.1 and 1.2.3 published under the wrong license (MIT rather than PIF) and need withdrawing.

Why yank rather than delete

crates.io offers no per-version delete. The only per-version mechanism is cargo yank, which keeps the version downloadable — so existing lockfiles keep building — while stopping any new resolution from picking it.

Deleting the whole crate is possible while it's young, but it would take the correctly-licensed 1.2.4 with it, briefly free the name, and drop the publishing config. Not worth it to remove two versions nobody has downloaded.

Why a workflow instead of a local cargo yank

The token is already a repo secret for crates-release.yml. Running the yank there means an urgent withdrawal doesn't depend on whoever's around having a token configured locally, and it leaves a trail in Actions.

--undo is supported, because yanking is reversible and being able to reverse it quickly is the whole point of preferring it to deletion.

gh workflow run crates-yank.yml -f version=1.2.1
gh workflow run crates-yank.yml -f version=1.2.3

It refuses if the version isn't published or the secret is missing, and prints the yanked state of every version afterwards.

Nothing depends on the versions being yanked

tish-gba is already on deckfile = "1.2.4" (schlopai/tish-gba#1), re-verified byte-identical across all 77 songs. crates.io reports 0 reverse dependencies and 0 downloads for both.

deckfile 1.2.1 and 1.2.3 published under the wrong license (MIT rather than
PIF), so they need withdrawing.

Yanking is the only per-version mechanism crates.io offers — there is no
per-version delete, and deleting the whole crate would take the correctly
licensed 1.2.4 with it, free the name, and drop the publishing config. A yanked
version stays downloadable so existing lockfiles keep building, but no new
resolution picks it.

Runs from CI against the CARGO_REGISTRY_TOKEN secret that crates-release.yml
already uses, so an urgent yank does not depend on whoever is around having a
token configured locally, and it leaves a trail in Actions. Takes an --undo
input, since yanking is reversible and being able to reverse it quickly is the
point.
@spacedevin
spacedevin merged commit a960b68 into main Aug 3, 2026
5 checks passed
@spacedevin
spacedevin deleted the chore/crates-yank-workflow branch August 3, 2026 23:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant