fix(ci): tag and upload each Conda Update bump exactly once (#1632)

[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort) — not run: all three lint pcapkit, and no pcapkit/ file changed

• make test passes, and a test case covers the change — ran the affected test files, not the whole suite

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• release — bumps the version or rolls up a distribution
• chore — anything else

---

Description of your pull request and other information

Closes #1632. Stacked on #1644, which lands first. Only the top commit is this PR's; the one below it is #1644's.

Cascade. conda-tag and conda-dist called no status-check function. "A default status check of success() is applied unless you include one of these functions" (GitHub, Evaluate expressions), so both were skipped behind the unit-tests gate, which skips on workflow_run (#731). Run 38325136710 pushed f4f94bcad, and both jobs reported skipped. Both jobs now start with !cancelled() and require their predecessors to have succeeded (cron-conda.yml:313, :393).

Unverified commits. Push Changes fetches the tip first. It pushes only if every commit a rebase onto that tip would bring in passes #1644's rule. The rule runs from this checkout's copy, via util/verdict_covers_checkout.py --head --exit-code (:230). If they don't pass, the step writes pushed=false, posts a notice, and the job stays green; the tip's own Unit Tests run raises the next bump. Conda Tag checks out and tags CONDA_COMMIT, the sha that was pushed (:333, :368), with no git pull. If the tag already exists on that sha, it is left alone and the job passes. If it exists on another sha, the job fails, the tag is not moved, and nothing is uploaded (:361).

Second runs. CONDA_CHANGED is now Push Changes' pushed output (:278). It is 'true' only while conda/build still differs from the tip after the rebase. I first said one Unit Tests run raised two triggers; that was wrong. Conda Update 38325136710 and 38325153882 were each raised 2 s after a different Unit Tests run completed: 38323045571 (9083163f5) and 38323026585 (01151b13f). Both were labelled 2e941bbb7, main's tip at the time. The 2026-10-10 pair on 9f37fb051, 38094603411 and 38094684143, came from 38093415347 and 38093432887 the same way. #1644 refuses all four runs. The guard still matters when two runs start from one checkout: the schedule plus a workflow_run, or a re-run.

Tests. test_release_gates.py (115 OK) adds CONDA_ROWS for both rebase cases (:1705, :1711). TestCondaPushReportsWhatLanded (:3913) and TestCondaTagTagsWhatWasPushed (:4154) run the real Push Changes, Create Tag and Push Tag against a local origin, with git's auto-maintenance off as in #1644 (guard at :4123). A git shim lands a merge between Push Changes' fetch and its rebase (:4046): the push is refused as a non-fast-forward, and the step fails having written nothing. With git pull --rebase for git rebase "$tip", that merge is pushed under the bump (:4067). With 9303afe's cron-conda.yml swapped in, unittest reports failures=16, errors=1; with #1644's, failures=24. I ran the 12 related test files one at a time on the previous head; on this one I re-ran test_release_gates, test_workflow_run_verdict, test_workflow_apt_timeouts, test_unit_tests_queue, test_conventions_doc_claims and test_tier_guard. All pass; I did not run the whole suite.

Not done. The five bumps #1632 lists stay unpublished, and conda-dist still has no environment:.

[JarryShaw]

Verdict: GOOD TO GO at 9303afe11. Sonnet cross-review, two rounds. Round 1 found that a duplicate workflow_run would fail at git tag. Round 2 confirmed the fix by running the real Push Changes script against local origins, and checked it against the logs of runs 38325136710 and 38325153882. With the fix reverted, 12 tests fail on origin/main's workflow and 8 on round 1's. I re-ran both counts myself. Open, not blocking: why one Unit Tests run fires workflow_run twice is still unexplained.

[github-actions]

Coverage: 89.66% (unit tier, Python 3.14, 9ac44a063, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18858	954	2366	868	91.06%
pcapkit/corekit	2366	67	760	35	96.48%
pcapkit/dumpkit	275	3	100	3	98.40%
pcapkit/foundation	2884	145	1010	35	94.14%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17166	226	4580	191	98.06%
pcapkit/toolkit	1036	168	386	5	82.35%
pcapkit/utilities	494	4	146	4	98.75%
pcapkit/vendor	4409	2342	1006	157	43.25%

Per-file detail: the coverage-html artifact of this run.

[JarryShaw]

Holding #1641: the label is now review: needs-changes. The #1643 review found a gap this PR opens. Once Conda Tag runs on workflow_run, Create Tag git pulls and tags HEAD (cron-conda.yml:262-263 here). If a human commit lands after the verified checkout, it can get tagged and uploaded without its own Unit Tests verdict. I'm folding the fix in here: tag the sha that Push Changes pushed, and refuse a rebase that brings in non-bot commits. This PR will be stacked on #1644, so please land that first.

[JarryShaw]

Verdict: GOOD TO GO at 9ac44a063. This head is stacked on #1644's c2ee06a1e, which should land first; only the top commit belongs to this PR. Sonnet cross-review, round 4.

• Round 3 closed the gap the fix(ci): act on a Unit Tests verdict only for the commit it covers (#1643) #1644 review found. Push Changes now pushes only over commits fix(ci): act on a Unit Tests verdict only for the commit it covers (#1643) #1644's rule covers, and Conda Tag tags the exact sha that was pushed, with no git pull.
• Round 4 rebased onto c2ee06a1e, turned off git auto-maintenance in this harness as fix(ci): act on a Unit Tests verdict only for the commit it covers (#1643) #1644 does, and pinned the rebase onto the sha it judged. A git shim lands a merge between the fetch and the rebase; git pull --rebase fails that test.

I re-ran both test files myself: test_release_gates 115 OK, test_workflow_run_verdict 26 OK. Not blocking: a merge landing between the fetch and the push turns the run red rather than skipping it. That is tracked in #1649.