ci: fix three defects blocking the 0.6.0 release - #212
Merged
Conversation
The publish job runs cargo test --workspace, which compiles rustmotion-studio and pulls in the GTK/WebKit stack backed by glib-2.0, but only installed fontconfig and freetype. glib-sys failed to build and the 0.6.0 release stopped at the test step, before any crate reached crates.io. dd4c1e4 added these packages to ci.yaml only; the two workflows have compiled different things ever since.
rustmotion depends on rustmotion-html 0.6.0 alongside core and components, but the workflow never published it and the crate does not exist on crates.io. The release would have failed at the third publish step, with core and components already permanently published — crates.io publishes cannot be undone, only yanked, so recovering means bumping the whole workspace.
highlight.rs reached the workspace-root themes/ through include_str!, four levels up and outside the package. cargo package only archives files under the crate, so the tarball shipped without them and the verify build failed on 65 missing files. Following rustc's suggestion of a fifth ../ would have been worse than the bug: it resolves only because the verify build runs inside target/package/ within the repo, so the dry-run would pass while producing a crate that cannot build for anyone downloading it from crates.io.
cargo test never builds a tarball, so nothing caught that rustmotion-components reached outside its own directory for 65 theme files until a tag was pushed. This job packages the published crates and rebuilds each from its archive, moving that discovery from release time to review time.
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.
The 0.6.0 release stopped at the test step. Fixing that alone would have made the
next attempt worse, not better: two further defects sat behind it, and the second
one only fires after
rustmotion-corehas been published — irreversibly.No issue tracks this; it was found by reading the failed run
(32265906716).
Nothing reached crates.io, so 0.6.0 is still free.
Three defects, in the order the release would have hit them
1.
glib-2.0missing — stopped the run before any publish.publish.yamlinstalledlibfontconfig1-devandlibfreetype6-dev, but runscargo test --workspace, which compilesrustmotion-studioand pulls in theGTK/WebKit stack.
dd4c1e4added the needed packages toci.yamlonly, so thetwo workflows have been compiling different things ever since.
2.
rustmotion-htmlwas never published, andrustmotiondepends on it.The workflow published core, components, then
rustmotion— which declaresrustmotion-html = "0.6.0", absent from crates.io. The release would have failedat the third publish with core and components already permanently published.
crates.io publishes cannot be undone, only yanked, so recovery meant bumping the
whole workspace to 0.6.1.
3. 65
include_str!reaching outside the crate.rustmotion-components/src/codeblock/highlight.rsread themes from theworkspace-root
themes/directory, four levels up.cargo packageonly archivesfiles under the crate, so the tarball shipped without them and the verify build
failed on all 65.
themes/(1.8 MB, 65 files) moved into the crate and the paths shortened to../../themes/. It was referenced from nowhere else in the repository.rustc's suggestion here is a trap and was not followed. It proposes a fifth
../, which resolves only because the verify build runs insidetarget/package/within the repo — five levels up lands back on the workspace root. Taking it would
make the dry-run pass while shipping a crate that cannot build for anyone
installing it from crates.io.
The guard
None of the three is reachable by
cargo test, which never builds a tarball. Allthree could only surface by pushing a tag, one release at a time. A
packagejobnow runs
cargo package --workspaceon every PR, excluding the two crates thatare not published so the GTK stack is not installed for nothing.
Verification
cargo package --workspace --exclude rustmotion-studio --exclude rustmotion-cliexits 0. All four publishable crates package and rebuild from their own tarball,
and the components archive contains all 65 theme files.
Packaging each crate individually still fails —
cargo package -p Xresolvesdependencies against the registry, and no rustmotion crate is published yet. That
is expected for a first release, not a remaining defect; the workspace form is
what resolves the members against each other.
Before re-tagging
A tag-triggered workflow is read from the tag's own commit.
0.6.0points atb785ced, which has none of this, so re-running the failed job would failidentically and merging here is not enough. Either move the tag onto the merged
commit — safe, since nothing was published and nobody can be depending on it — or
cut 0.6.1.