fix: build, release and connect without a committed lockfile - #43
Merged
Conversation
added 3 commits
September 9, 2026 17:26
`cargo pkgid` resolves the dependency graph, so it requires a `Cargo.lock`.
This repo stopped committing one, and the command has failed ever since:
error: a Cargo.lock must exist for this command
The step did not fail with it. `VERSION` was assigned the empty string from a
failed substitution, the job continued, and the bundle verification compared
`0.1.37` against nothing:
##[error]bundle reports 0.1.37 but this release is
So 0.1.37 was merged, built and signed, and never published.
`cargo metadata --no-deps` reads the workspace manifests without resolving
anything, needs no lock, and creates none. Verified both ways with the lock
moved aside: it returns 0.1.37 offline, while `pkgid` reproduces the error
above.
The empty-version guard is the other half. A release that cannot name itself
should stop rather than publish under a blank version.
`build_frontend` ran unconditionally, so `cargo build --bin chuzz-headless
--no-default-features` shelled out to `bun run build` in
`apps/chuzz/frontend` for assets that binary never links. `frontend.rs` is
the only consumer of the generated module and is already behind `gui`.
On a machine without `apps/chuzz/frontend/node_modules` the build script
panicked instead:
error: script "layouts:local" exited with code 127
error: script "prebuild" exited with code 127
That is every runner using the `headless-host` action, which installs the
site under test's dependencies and has no reason to install this crate's, so
the whole fleet's QA went red in the host build step.
Verified both ways with `node_modules` moved aside: the headless build now
finishes, and `--bin chuzz-gui` still fails there with the error above,
which is the proof the gate did it rather than something else.
The helpers move behind the same feature so an unused import does not become
a denied warning.
`rustls` picks its provider from crate features and panics at the first handshake when the graph enables neither `ring` nor `aws-lc-rs`, or both. Features are additive across a graph, so which of those holds is an outcome of resolution rather than a decision anyone made, and with no lockfile it is not fixed at any point in time: one dependency picking up `ring` in a later release is enough to turn every `https://` fetch and every `wss://` connection into a panicked worker on the next runner that resolves it. It was hit on a fresh resolution during QA work, on `rustls 0.23.43`, and went away on re-resolution to 0.23.44. Today's graph enables `aws-lc-rs` alone, so this is latent rather than reproducible here, which is exactly the problem: nothing holds it there. The failure does not look like a browser failure. The socket never opens, Solid halts reactivity on the escaped error, and the page collapses to unnamed nodes, so a QA run reports a broken site. Both binaries now install a named provider before anything can reach the network. Verified by capturing an https page end to end.
pathscale
changed the title
pathscale
force-pushed
the
fix/release-version-without-lockfile
branch
from
September 9, 2026 11:06
70e190c to
94f3f04
Compare
pathscale
changed the title
pathscale
changed the title
The corpus tooling was rewritten out of the repository, so nothing under scripts/corpus is Python any more and no build step produces bytecode. The ignore rule outlived the files it was written for. Leaving it in place is worse than merely dead. Python is not allowed in this tree, and an ignore rule for its bytecode is the one thing that would keep a reintroduction out of git status, so the rule quietly works against the convention it now has nothing to serve.
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.
Merge last. This is the final merge of the cycle: merging it is what publishes chuzz, so it lands after the engine repos have published and their bumps are in here. Merged at any other point it ships a version without the engine fixes.
Three failures with one cause: dropping the committed lockfile removed assumptions three places were relying on. Each is verified in both directions.
1. The release could not read its own version
cargo pkgidresolves the dependency graph, so it needs aCargo.lock. It has failed on every release run since we stopped committing one, and it did not fail the step:VERSIONtook the empty string from the failed substitution and the job carried on to compare the bundle against nothing.That is why 0.1.37 is on master and was never published.
cargo pkgid -p chuzz-guierror: a Cargo.lock must exist for this commandcargo metadata --no-deps ... | sed ...0.1.37, and creates no lockThe empty-version guard is the other half: a release that cannot name itself now stops rather than publishing under a blank version.
2. A headless build built the browser chrome, and took the fleet's QA red
build_frontendran unconditionally, socargo build --bin chuzz-headless --no-default-featuresshelled out tobun run buildfor assets that binary never links.frontend.rsis its only consumer and is already behindgui.Without
apps/chuzz/frontend/node_modulesthe build script panicked instead, which is every runner using theheadless-hostaction:Verified with
node_modulesmoved aside: the headless build finishes, and--bin chuzz-guistill fails there with the error above. That second half is the proof the gate did it.3. TLS picked its provider by resolution
rustlsselects its crypto provider from crate features and panics at the first handshake when the graph enables neitherringnoraws-lc-rs, or both. Features are additive across a graph, so with no lockfile that is not fixed at any point in time: one dependency picking upringin a later release turns everyhttps://andwss://into a panicked worker on the next runner that resolves it.It was hit on a fresh resolution during QA work on
rustls 0.23.43and went away on re-resolution to 0.23.44. Today's graph enablesaws-lc-rsalone, so it is latent rather than reproducible here, which is the problem: nothing holds it there.It does not present as a browser failure. The socket never opens, Solid halts reactivity on the escaped error, and the page collapses to unnamed nodes, so a QA run reports a broken site.
Both binaries now install a named provider before anything reaches the network. Verified by capturing an https page end to end.
The engine dependency bumps land here too, before merge, so 0.1.37 publishes exactly once carrying all of it.