Repository navigation
fix(build): an unlabelled release image is adopted only from a pinned release - #1152
Merged
antoinetoussaint-byte merged 1 commit intoOct 25, 2026
Conversation
… release A released tag whose image predates per-class build labels records only the aggregate input key, so its code cannot be compared with this build's. #1148 adopted it anyway, from any source: an edited checkout whose version did not move would be handed the earlier release's image, with a warning and nothing compared. It is now adopted only when the service builds from a pinned release the CLI materialized — under the git-clone or verified-package cache roots, which hold nothing but CLI output — because that code is the release's by construction. From a checkout or an override it refuses, naming the two ways out. A root configured through CODEFLY_MODULE_CACHE is never proof: a developer may keep their own checkouts there. The cache roots move to a leaf package, pkg/modulecache, so the builder can ask without an import cycle; pkg/composition delegates to it unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
Why
Audit of #1148 (unreleased). A released tag whose image predates per-class build labels records only the aggregate input key, so its code can't be compared with this build's. #1148 adopted such an image from any source. That means an edited checkout whose version didn't move would ship the earlier release's image, with only a warning.
What
CODEFLY_MODULE_CACHEnever counts as proof, since developers may keep their own checkouts there. This matches howpkg/compositionalready treats that root for ownership.pkg/modulecache, sopkg/orchestrationcan ask without importingpkg/composition(which imports it).pkg/compositiondelegates to it.Classification: fix at the owner (the adoption verdict). Reused: the existing cache roots and their ownership rule. Nothing new decides ownership.
Effect on today's cells: renders of pinned modules from the module cache, which is how obin-blue and obin-staging render, keep adopting the unlabelled releases. Only a checkout render is refused.
Docs:
docs/commands.md(the published-release verdict table).Tests
TestAPublishedVersionLabelledBeforeClassesIsAdoptedFromAPinnedReleaseand…IsRefusedFromACheckoutcover both sides.TestPublishedReleaseVerdictNamesTheClassandTestAPublishedReleaseIsJudgedByItsCodecover the checkout row.pkg/modulecacheTestOwnedIsOnlyTheCLIsOwnRoots.go test ./pkg/orchestration ./pkg/composition ./pkg/modulecachepasses.🤖 Generated with Claude Code