Repository navigation
ci: this repo's own emitter job could not pass at any commit - #18
Merged
Merged
Conversation
main has been red since 21e3b44. Every commit since -- f32a41b, 5acddfc -- failed the `emitter` job for the same reason, and it was not any of them. #628's commit binding refuses a bundle whose emission was produced at one commit and whose environment describes another. It is right to: that pairing attests commit B's subject with commit A's declaration content, and every other rule stays green while it happens. This job hits it structurally. The emission is LIVE, generated from the checkout one step earlier. The environment is a FIXTURE pinned to bridgeland-stab-lean's f166a3d. They can never agree, so the job became unpassable at every commit the moment the binding landed -- not flaky, not commit-specific, simply impossible. Re-pointing the fixture's rev at the checkout is the repair rather than weakening the check, because this pairing was never a trust record. README already says so: "this repo's own CI cannot produce a real environment record for itself, and its use of the fixture is a test of the emitter rather than a trust record." A real record is not available either -- `mfc env` needs the contract package in a lake manifest, and this package deliberately has no dependencies at all. `tag` is nulled in the same copy. Leaving the fixture's `v0.1.0` would be a lie in the other direction: this checkout is not that release, and `seal` reads `tag` straight into subject.digest.gitTag. The binding keeps full strength everywhere it is a trust claim -- a topic repo, where both artifacts are real, and the contract job's fixtures, which pair fixture with fixture. Only this one job, which pairs live with fixture, opts out, and it says why in twenty lines rather than a flag. Verified locally: with the emission regenerated at HEAD and the fixture rev re-pointed, `mfc bundle` writes 285 declarations and validates.
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
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.
main has been red since
21e3b442(2026-08-19 02:56). Every commit since —f32a41b,5acddfc— failed theemitterjob for the same reason, and it was not caused by any of them. I merged two PRs onto that red main without checking, which is how it went unnoticed for the day.Why it cannot pass
#628's commit binding refuses a bundle whose emission was produced at one commit and whose environment describes another. It is right to — that pairing attests commit B's subject with commit A's declaration content, and every other rule stays green while it happens.
This job hits it structurally:
f166a3dThey can never agree. The job became unpassable at every commit the moment the binding landed — not flaky, not commit-specific, simply impossible.
Why re-point the fixture rather than weaken the check
This pairing was never a trust record, and the README says so already:
A real record is not available either:
mfc envneeds the contract package in a lake manifest, and this package deliberately has no dependencies at all.So the emitter job copies the fixture, sets
root_package.revtoGITHUB_SHA, and bundles against that.tagis nulled in the same copy — leaving the fixture'sv0.1.0would be a lie in the other direction, since this checkout is not that release andsealreadstagstraight intosubject.digest.gitTag.The binding keeps full strength everywhere it is a trust claim: a topic repo, where both artifacts are real, and the contract job's fixtures, which pair fixture with fixture. Only this one job — the one pairing live with fixture — opts out, and it explains itself in the workflow rather than behind a flag that the next caller to hit the error would reach for.
Verified
Emission regenerated at HEAD, fixture rev re-pointed:
mfc bundlewrites 285 declarations and validates.Unblocks #17, which is failing on this and nothing else.