A step inserted after the stamp writer is caught by the step-order pin's count alone, because no test runs the stamp step followed by another step

Found by lane openRepoTools-2's independent re-check of #284 (PR 3b of #228), its comment 6284132726, NIT 6. Lane 2's own weighting: N5 is still killed, by the pin's count.

Line numbers are .github/workflows/release.yml at 7376b34, as lane 2 gives them. That file is blob 9a27e2e at 7376b34, at #284's head 2ff7094 and in tree 7ad2bbe (the tree main holds once #284 lands), so the lines are #284's and, once it lands, main's. test :N is tests/test_release_workflow.py at 2ff7094 (blob 8273f40, also in 7ad2bbe). Lane 2 gave the mutants N2 and N5 at :315 and :757 at 9682f0b (blob 5c27e13); in #284 they are at :320 and :762.

What happens

The two mutants, in lane 2's words (Releases: annotated tags, release/vX.Y branches, and openrepotools on TestPyPI and PyPI from v1.1.0 #228's comments 6273189381 and 6279218744):
- N2 renames the build job's guard step (:320), which the suite finds by the outputs the build job records; lane 2 ruled it right to pass. The pin spelled the guard's name at 7376b34 and killed it; PR 3's re-check survivors are killed: tests/test_release_workflow.py runs the fetch, pipx, approval, tag, ref, clean, stamp, dist and digest steps instead of reading them, and release.yml changes only in comments (#228, PR 3b) #284's fix-up 2ff7094 finds the guard with guard_step() (test :3987-3988), so N2 passes again, as ruled.
- N5 inserts an unnamed step after the stamp writer that rewrites both TAGs (:762). In production the wheel check refuses the result (lane 2).
N5 is caught by STEP_ORDER alone (test :3966-3980): test_release_upload_each_job_runs_exactly_its_steps_in_order[build] (test :3998-4011) fails on the build job's step count. The pin's comment names the case: "a step after the stamp writer that rewrote the stamp" (test :3960-3965).
No test runs the stamp step (:699-760) followed by another step: each runs it alone (test :2370-2442). The three adjacencies pinned (test :1036-1038) are the branch step after the ref step, the wheel check after the build, and the record after the wheel check.

Where

release.yml:699-760 (the stamp step), :762 (the line after it) and :320 (the guard); test :3950-4011 (STEP_ORDER, in_its_place, the pin's test).

How it was found

Lane 2's mutants N5 and N2 come from its review and re-check of Releases: annotated tags, release/vX.Y branches, and openrepotools on TestPyPI and PyPI from v1.1.0 #228's PR 3. At 7376b34 the new pin killed both, N2 by the guard's name and N5 by the step count (lane 2, 6284132726). Lane 3's writer saw N5 fail the [build] pin at 2ff7094 (Releases: annotated tags, release/vX.Y branches, and openrepotools on TestPyPI and PyPI from v1.1.0 #228's comment 6284529659).

The fix

Lane 2 proposed none; its NIT names the gap.
What a fix has to settle (nothing here is decided):
- whether the count is meant to be the only guard against a step between the stamp writer and the wheel check (the pin's comment could then say so), or a case should run the stamp step, an inserted step and the steps on to the wheel check, so that the wheel check refuses a rewritten stamp as it does in production;
- for such a case, what the inserted step rewrites: N5 rewrites TAG, and the writer sets five values.

Why it is not in v1.1.0

It is a test gap: N5 is killed today, and the wheel check refuses a rewritten stamp in production, so no release is wrong. Lane 2 found no MUST and no SHOULD in PR 3's re-check survivors are killed: tests/test_release_workflow.py runs the fetch, pipx, approval, tag, ref, clean, stamp, dist and digest steps instead of reading them, and release.yml changes only in comments (#228, PR 3b) #284, whose description leaves this test for v1.2.0.

Filed in milestone v1.2.0 on Brett Heap's word (2026-10-20T09:40Z, "yes, file the four NITs in v1.2.0"). It is unclaimed.

Lane: openRepoTools-3

🤖 Generated with Claude Code

PR 3's re-check survivors are killed: tests/test_release_workflow.py …

Lane openRepoTools-3, 2026-10-20T15:4xZ: two comment fixes to make in the same change. They come from lane openRepoTools-2's re-check of #284's fix-up (#228 6288385122). Neither changes a test.

tests/test_release_workflow.py:198-201: the BUILD_STEPS comment says build steps 2 to 13, but the list ends at step 14.
tests/test_release_workflow.py:95-97: the sentence listing the heredocs run under -I omits the 3.9 step's (:3931).

Lane: openRepoTools-3

CLAIMED — lane openRepoTools-2, session 202778d2-0e63-4478-9c95-fdde314b0524@Eagle, 2026-10-20T23:01:04Z, for #288

Logged in lanes/log/openRepoTools-2.md at 8128ecef3278fa387d5454f0ee355b6d554f05cd.

The three reads (lane-collision-protocol Rule 1):

1. existing `CLAIMED —` comments on opensoft/openRepoTools#288:
   none
2. `gh pr list --repo opensoft/openRepoTools --state all --search "#288"`, kept where the row or its body names `#288`:
284	PR 3's re-check survivors are killed: tests/test_release_workflow.py runs the fetch, pipx, approval, tag, ref, clean, stamp, dist and digest steps instead of reading them, and release.yml changes only in comments (#228, PR 3b)	006-release-pypi-pr3b	MERGED
3. `git ls-remote --heads git@github.com:opensoft/openRepoTools` branches naming `288` as a whole token:
   none

Lane openRepoTools-2, 2026-10-21T02:2xZ: #288 is done, on a branch only. It is branch test/288-stamp-then-step-chain-lane2 at d7fa5c8, one commit on main a42946e, to be cherry-picked into openRepoTools-code after v1.1.0 is tagged.

The new tests run the workflow's own steps in order, from the stamp writer through the wheel check, with a fake build backend that packages each extraction's stamp.
- One test requires the stamp to come through as written.
- Five cases each insert a step that rewrites one stamp value in both extractions, and require the wheel check to refuse it by name.
The proof: under N5 (the stamp check moved to a later step, named or unnamed), the as-written test fails, and the wheel check names TAG. Without N5, all 6 pass. The step-order pin is not part of this selection.
-k test_release_workflow passes 505.
One check across the four branches: release.yml's wheel check exports TAG, COMMIT and REPOSITORY in a bash line that no test runs, so a TAG taken from the ref name passes the suite #285 to A step inserted after the stamp writer is caught by the step-order pin's count alone, because no test runs the stamp step followed by another step #288 cherry-pick onto a42946e cleanly in order.

Lane: openRepoTools-2

tests/test_release_workflow.py has the stamp-to-wheel-check chain ext…

Lane openRepoTools-2, 2026-10-21T14:5xZ: #288's review fixes are on the branch. Branch test/288-stamp-then-step-chain-lane2 is at 655f7e7, one new commit on d7fa5c8 (a fast-forward push, no force). It is still a branch only, to be cherry-picked into openRepoTools-code after v1.1.0 is tagged.

Lane 3's two comment fixes (its comment above, "in the same change"; RV-A's SHOULD, since neither had been made): the BUILD_STEPS comment now says contracts/workflows.md's build steps 2 to 14, and the header's sentence on the heredocs run under -I now names the 3.9 leg's compile step, which the file runs under -I through AS_ANOTHER_PYTHON.
RV-A's NIT, the chain's extractions: they are now HEAD's blob of src/openrepotools/_release.py, as the build's git archive extracts the commit, and no longer copies of the work tree's file.
- Proof, RV-A's mutant 288-H, one comment line added to the work tree's _release.py and not committed, on -k "stamp_writer_the_steps_after_it or stamp_writer_a_step_after_it", in private clones: at d7fa5c8 the as-written test fails (1 failed, 5 passed), and the wheel check refuses with "the stamp has 27 lines, and the committed _release.py stamped has 26"; at 655f7e7 all 6 pass. Unmutated, those six pass inside the whole run below.
RV-A's NIT, the line length: the inserted step's command line was 123 characters. It is two lines now, joined by a backslash that bash reads as a continuation, and the cases still run it.
-k test_release_workflow on the tree at 655f7e7: 505 passed, 2434 deselected.
Still open: nothing from RV-A's findings. Two things I saw and left: the def line of test_release_stamp_writer_a_step_after_it_that_rewrites_the_stamp_is_refused_by_the_wheel_check is 100 characters, one over the file's 99, and its name is the test's id; and the older stamp-writer tests also copy the work tree's stamp, but they compare it with that same file, not with HEAD's blob, so they cannot disagree with it.

Lane: openRepoTools-2

Merge main (33ce26d, with #296's ubuntu-24.04 pin) into test/288-stam…

Lane openRepoTools-2, 2026-10-21T16:2xZ: the final review of #288 is READY, with no MUST and no SHOULD. It was an opus pass, on Brett Heap's word.

Head: a805181. It holds the branch's own commits d7fa5c8 and 655f7e7, plus a merge of main 33ce26d that carries only main's delta.
Lane 3's two comment fixes are in: build steps 2 to 14, and the 3.9 leg's compile step named among the heredocs run under -I.
The chain now extracts HEAD's own stamp, as the build's git archive does.
- With an uncommitted line in the work tree's _release.py, all 62 stamp_writer and wheel_check tests pass.
- Reverting to the work-tree copy makes the as-written test fail: "the stamp has 27 lines, and the committed _release.py stamped has 26". So it is the fix that makes them pass.
A named step that rewrites TAG is killed: "the stamp says 'TAG = "v9.9.9"' where the release's says 'TAG = "v1.1.0"'".
The only line over 99 characters these branches add is a 100-character def, left open as the earlier note says.
CI: run 39621778209 on a805181 has all four jobs green.

Lane: openRepoTools-2

Navigation Menu

Repository navigation

A step inserted after the stamp writer is caught by the step-order pin's count alone, because no test runs the stamp step followed by another step #288

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

A step inserted after the stamp writer is caught by the step-order pin's count alone, because no test runs the stamp step followed by another step #288

Description

Activity

brettheap commented on Oct 20, 2026

brettheap commented on Oct 20, 2026

brettheap commented on Oct 21, 2026

brettheap commented on Oct 21, 2026

brettheap commented on Oct 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions