chore(release): 0.6.1, published as one workspace - #213
Merged
Conversation
0.6.0 cannot be reused: rustmotion-core 0.6.0 reached crates.io before the run failed, and a published version is permanent. Moving every crate to 0.6.1 keeps the four in lockstep and leaves no version half-taken.
The seven hand-rolled steps polled https://crates.io/api/v1/crates/<name>/<version> to wait for each crate. That endpoint rejects requests without an identifying User-Agent, so the loop could never succeed — it always spent 150s and exited 1. The 0.6.0 run died there, after rustmotion-core had already been published. cargo publish --workspace packages and rebuilds every selected crate from its own tarball before uploading anything, then uploads in dependency order and waits for index propagation itself. Nothing ships unless all of it can.
The version was written ten times — one per manifest, plus one per internal dependency requirement. Nothing kept them in agreement, and a single stale one fails the publish after the earlier crates have already shipped, which cannot be undone. [workspace.package] and [workspace.dependencies] now hold it; the six crates inherit. The tag check reads cargo metadata instead of grepping a manifest, since the manifest no longer contains a literal to grep.
[workspace.package] now holds the version and the six crates inherit it, but cargo cannot inherit it into a dependency requirement: an entry in [workspace.dependencies] must carry a literal, because a published crate cannot depend on a bare path. So the package version and the three internal requirements can silently disagree, and cargo only notices at publish time — once the earlier crates are already on crates.io. The check fails on either kind of drift: a requirement that no longer matches the workspace version, or a crate that stopped inheriting it.
publish = false in the studio and cli manifests already keeps them out of cargo publish --workspace and cargo package --workspace, verified by running both without the flags: cargo selects exactly the four publishable crates. Repeating that in the workflow duplicated a fact the manifests already carry.
cargo publish --workspace and cargo package --workspace do not treat publish = false the same way. publish skips those crates; package archives them anyway and fails on rustmotion-studio, which depends on rustmotion by path with no version — an unversioned dependency cannot be packaged. Removing the flags from both commands generalised a check run only against publish. Reproduced locally: with the excludes the job exits 0, without them it exits 101 on that manifest.
cargo publish --workspace already packages and rebuilds every crate from its own tarball before uploading anything, so a packaging defect now fails the release with nothing published. Repeating that work on every PR guarded against a risk the tag workflow already removes.
The publish step already packages and verifies every crate before uploading, so this catches nothing new and rebuilds all four a second time. What it buys is a readable failure: a packaging defect now stops before the publish command runs at all, so the log cannot be mistaken for a release that started and broke halfway — which is how 0.6.0 ended, with one crate already on crates.io.
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.
0.6.0 is unrecoverable:
rustmotion-core 0.6.0reached crates.io before the rundied, and a published version is permanent. This moves the workspace to 0.6.1 and
replaces the publish sequence with one that cannot repeat the failure.
No issue tracks this; it follows the failed run
32287388143.
Refs #212.
What actually failed
Not propagation timing. The wait loops polled
https://crates.io/api/v1/crates/<name>/<version>, and that endpoint rejectsrequests without an identifying User-Agent under the crates.io data access
policy.
curl -sfreads the rejection as failure, so the loop could neversucceed: it always spent its 150 seconds and exited 1.
The job therefore published
rustmotion-core, then failed at the step meant toconfirm it. Everything downstream was skipped.
The same broken check misled the investigation of #212, where it reported "not
published" for crates that were. The authoritative source is the sparse index at
index.crates.io— what cargo itself reads — and it showsrustmotion-core 0.6.0present and unyanked.
The guarantee this PR buys
Seven hand-rolled steps become one:
Cargo packages and rebuilds every selected crate from its own tarball before
uploading anything, then uploads in dependency order and waits for index
propagation itself. If one crate fails to build from its archive, nothing ships.
That is the property the previous sequence never had: it published crate by
crate, so a defect in the fourth was discovered with the first three already
permanent.
No crates.io API call remains, so the User-Agent problem is gone rather than
worked around.
Why 0.6.1 rather than finishing 0.6.0
The three remaining crates could have been published at 0.6.0 — they depend on
rustmotion-core 0.6.0, which now exists. Bumping instead keeps the four inlockstep and sidesteps an open question: whether
cargo publish --workspaceskips an already-published version or stops on it. On an irreversible path that
question is not worth answering live.
rustmotion-core 0.6.0stays on crates.io as a stray version. Yanking it is aseparate decision and is deliberately not part of this PR.
Verification
cargo publish --workspace --exclude rustmotion-studio --exclude rustmotion-cli --dry-runexits 0. All four crates package at 0.6.1, rebuild from their owntarball, and the upload order is core → html → components → rustmotion.
cargo fmt --all --checkis clean.Before tagging
A tag-triggered workflow is read from the tag's own commit, so
0.6.1must becreated after this merges, on the merge commit.