feat(release): stamp eval.input-hash on every pushed image - #303
Merged
Conversation
Rung 3 of the carried-forward ladder (#292; primitive merged in #298): every push site now records the image's build-input hash in its config (delivery/RULES.md rule 12), the value rungs 4-5 will diff and retag on. Per-target --set at every bake site — never *.labels, because a single invocation bakes targets with different hashes (bases bakes ~19, combos bakes eval + eval-standalone): - bases: one fleet-hash run, one --set per shared dep - leaves: --set "$T.labels.eval.input-hash" from the leaf's row - per-task bake (swe-bench): per-task hash via fleet-hash per-task - per-task script (terminal-bench, skills-bench): build.sh gains an optional EVAL_INPUT_HASH env hook -> --label on the final build (this path has no bake invocation to --set) - combos: fleet-hash combo <b> <a> [task] — the new optional task arg mixes the task id into the hash exactly like per-task does and names rows with the release's <bench>-<tid> convention. No-task hashes are byte-identical to the frozen #298 definition (verified against the merged script across all 153 targets + combos). Label semantics: the hash records the repo-computed inputs at the stamped commit. On a frozen-bases dev dispatch a leaf may build FROM an older base than its hash's base component claims; tagged releases always rebuild bases first, so release labels are exact (noted inline). All three --set shapes verified locally via bake --print: per-target labels land on their own targets only. Signed-off-by: Elron Bandel <elron.bandel@ibm.com>
Signed-off-by: Elron Bandel <elron.bandel@ibm.com>
This was referenced Aug 9, 2026
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.
Resolves #302. Rung 3 of #292's migration path (rules #293, hash primitive #298).
What
Every push site in the fleet release now stamps
eval.input-hash— the image's build-input hash — into the image config (delivery rule 12). No build behavior changes; the label is the value the freshness diff (rung 4) and selective retag (rung 5) will consume.fleet-hashrun → one--set "<target>.labels…"per dep--set "$T.labels…"from the leaf's row (~0.4s/job)fleet-hash per-task <b> <task>→ per-target--setbuild.shgains an optionalEVAL_INPUT_HASHenv hook →--labelon the final build (no bake invocation exists on this path)fleet-hash combo <b> <a> [task]→ one--setper targetNever
*.labels— the #298 audit flagged this exact trap: a single bake invocation covers targets with different hashes (bases bakes ~19, combos bakes both variants), so a wildcard would stamp one wrong value everywhere.Script change (additive only)
fleet-hash comboaccepts an optional[task]: mixes the task id into both hashes exactly the wayper-taskdoes, and names rows with the release's<bench>-<tid>convention. The frozen definition is untouched — verified by diffing full output against the merged #298 script: byte-identical for all 153 targets and the no-task combo rows.Label semantics (the open decision from the audit, resolved)
The label records the repo-computed inputs at the stamped commit. On a frozen-bases dev dispatch, a leaf can build FROM an older frozen base than its hash's base component claims — accepted and documented inline, because tagged releases always rebuild bases first (nothing exists at a fresh
:TAG), so labels are exact where rules 13–14 gate.Verification
--setshapes exercised locally viabake --print: per-target labels land on their own targets only (bases multi-target, leaf single-target, combo eval+standalone with distinct hashes).tests/static/input_hash.rsextended: per-task combo rows follow the naming convention, track the task id, and differ from the shared combo and the standalone variant. Suite green (4 tests, ~6.8s);fleet-hash.sweep.shgreen (153 targets, both directions).dry_run=truedispatch on this branch exercises the bases/leaves label path via--print.Rules checked against
.agents/contributing/RULES.md1–3 (resolves drift drift: delivery/RULES.md#12 — no push site records the build-input hash in the image config #302; code-only; this section)..agents/delivery/RULES.md12 (implemented), 11 (task id and per-target hashes are inputs), 5 (no publish-trigger change)..agents/RULES.md12 (EVAL_INPUT_HASHenv prefix), 15.f (labels stamped on the invocation, never in bake files).tests/static/RULES.md1–3 (test additions offline, <30s, never ignored).