fix(hash): repair main after #14093/#14215 merged in reverse order - #14253
Merged
Merged
Conversation
…d in reverse order The plan documented in both PRs had docker#14215 land first, then docker#14093's compose-go bump delete the transient TestServiceHashContinuity. Merged in the opposite order, main's pkg/compose tests no longer even compile: richServiceFixture sets fields the container-spec layering turned into promoted embeds (struct literals require go1.27 for that), and once compilable two tests fail by construction. - richServiceFixture is built by assignment; - TestServiceHashContinuity is deleted, exactly as its own comment prescribes: the layered compose-go is the reorder it existed to outlive, its proof duty (pinned == historical bytes) is done, and TestHashGoldenValues carries the continuity contract alone — it PASSES on the layered compose-go, confirming the pinning preserved every historical hash through the layering; - pull_refresh_after, newly exposed at the service root, is appended to serviceHashKeyOrder: the fallback already emitted it in that exact position, so no hash moves — listing it only freezes the layout and satisfies the coverage walker. Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
glours
enabled auto-merge (rebase)
September 22, 2026 08:58
docker-agent
left a comment
docker-agent
left a comment
Contributor
There was a problem hiding this comment.
Assessment: 🟢 APPROVE
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
3 participants
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 PR does, in one sentence
Repairs main after #14093 and #14215 merged in the reverse of their documented order:
pkg/composetests compile again, the transient continuity test is deleted as planned, and the frozen key list learns the one attribute the compose-go layering added.Context
Both PRs documented the same plan: #14215 (the pinned-historical-order hash) lands first, then #14093's compose-go bump deletes
TestServiceHashContinuity— a test true by construction only while compose-go's struct order matches the frozen list, whose whole purpose was to prove the pinned serializer reproduced the historical bytes and then die with the reorder. They merged in the opposite order, and #14215 was never re-tested against the post-jobs main: on today's main,go test ./pkg/composedoes not even compile (richServiceFixturesets fields the container-spec layering turned into promoted embeds — struct literals require go1.27 for that), and once compilable, two tests fail exactly as the design predicted.What the PR brings
The fixture is built by assignment;
TestServiceHashContinuityis deleted, its proof duty done — and the decisive check holds:TestHashGoldenValuespasses unchanged on the layered compose-go, confirming the pinning preserved every historical hash through the reorder and closed the window between the two merges where main produced moved hashes (no release shipped in that window).pull_refresh_after, newly exposed at the service root by the layering, is appended at the end ofserviceHashKeyOrder: the unknown-keys fallback already emitted it in that exact position, so no hash moves — listing it only freezes the layout and satisfies the coverage walker.One follow-up question deliberately NOT taken here (this PR is a zero-decision repair):
pull_refresh_afteris a sibling ofpull_policy, which is excluded from the hash — it may deserve the same exclusion, but that is a semantic choice for its own change.🤖 Generated with Claude Code