the measurement can run against an engine that has not been released - #452
Merged
Sunrisepeak merged 2 commits intoSep 20, 2026
Merged
Conversation
Every ecosystem repository mcpp's changes reach already honours `MCPP_SOURCE_REF`: non-empty, it builds the engine from that ref and asserts that the binary on PATH is the one it built. This workflow was the gap, and it is the one that matters most --- mcpp's own CI cannot see a defect that appears only in a real dependency graph, and this repository holds thirty of them. THE COST OF THE GAP IS MEASURED, NOT HYPOTHETICAL. 2026.9.20.1 shipped on 2026-09-20. Within a day the four members that stop at `#include <windows.h>` through a borrowed `__CYGWIN__` --- archive, sqlite3, mimalloc, c-ares --- made a second release necessary. That reading was available from these same thirty graphs before the first release merged; nothing could produce it, because this job could only install a published engine. A release is not one build. It is a tag, four platform builds, two mirrors, a GET check per asset, an xim-pkgindex bump, an index artifact, and a consumer-side confirmation. What this closes is a second pass down that whole chain. Shape: the released engine the pin names is still installed, because mcpp builds itself and is its own bootstrap; the build from the ref then replaces it on PATH, and `MCPP_HOME` follows it. `.xlings.json` is removed from the clone first --- it pins the mcpp that compiles mcpp, does not move when mcpp is released, and would otherwise ask the index for a version it may no longer carry. The version under review is printed, because a PATH entry that does not win looks exactly like one that does until something has been measured with the wrong engine. The pins-agree check is unaffected: it compares this workflow's pin with pins.toml, and both still name the released version. A source ref is an override on top of that agreement, not a replacement for it.
The first revision prepended the freshly built `mcpp` to PATH beside its own
`target/` directory. The measurement then stopped at
error: xlings binary not found
A released archive carries a BUNDLED xlings that mcpp resolves relative to its
own location; a binary sitting in a build tree has no such neighbour, and
moving `MCPP_HOME` to that tree moved the search with it.
Overwriting `bin/mcpp` inside the released root instead keeps everything about
that root as the release left it --- the bundled xlings, the layout,
`MCPP_HOME`, the PATH entry already exported --- and changes only the one file
under review. The version is reported from the path the measurement will
actually run, because a copy that did not land looks exactly like one that did
until something has been measured with the wrong engine.
Found by using this mechanism on its first real cross-verification, which is
where a plumbing defect is cheap.
Sunrisepeak
deleted the
the-measurement-can-run-against-an-unreleased-engine
branch
September 20, 2026 18:31
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 this adds
MCPP_SOURCE_REF— non-empty, the measurement builds mcpp from that ref and runs the thirty member graphs against it instead of the released pin. Every ecosystem repository mcpp reaches already honours this variable; this workflow was the gap, and it is the one that matters most: mcpp CI cannot see a defect that appears only in a real dependency graph, and this repository holds thirty of them.The cost of the gap is measured, not hypothetical
2026.9.20.1 shipped on 2026-09-20. Within a day, the four members that stop at
#include <windows.h>through a borrowed__CYGWIN__—archive,sqlite3,mimalloc,c-ares— made a second release necessary.That reading was available from these same thirty graphs before the first release merged. Nothing could produce it, because this job could only install a published engine.
A release is not one build: a tag, four platform builds, two mirrors, a GET check per asset, an xim-pkgindex bump, an index artifact, a consumer-side confirmation. What this closes is a second pass down that entire chain.
Shape
MCPP_HOMEfollows..xlings.jsonis removed from the clone first: it pins the mcpp that compiles mcpp, does not move when mcpp is released, and would otherwise ask the index for a version it may no longer carry.The pins-agree check is unaffected: it compares this workflow pin with
pins.toml, and both still name the released version. A source ref is an override on top of that agreement, not a replacement for it.