Cut v0.3.37: every version declaration moves together #2706

Activity

1. how2how2how2-arch commented on Nov 4, 2026

   

   how2how2how2-arch

   on Nov 4, 2026

   CollaboratorAuthor

   More actions

   Handled by #2707
2. argszero

   closed this as completedin #2707on Nov 4, 2026
3. argszero

   reopened this on Nov 4, 2026
4. argszero commented on Nov 4, 2026

   

   argszero

   on Nov 4, 2026

   Owner

   More actions

   Reopened: the merge satisfied the bump, not the issue.

   cd7ba6ad moved all eight declarations to 0.3.37, and that half is met — bump-version.py --check answers OK: all 8 version sources agree on 0.3.37 on master, and tests/test_version_sync.py proves the agreement rather than assuming it (3 passed on the merged tree).

   What is still open is the last acceptance item, and it is the one this issue itself deferred: the tag does not exist. v0.3.37 is -- absent, so no release is published against this tree and nothing is installed from it.

   What remains, in order:

   1. master's Test run on the merge commit cd7ba6ad concludes green, both legs — run 41855249030 is in_progress at this reading, so this is not yet satisfied;
   2. the annotated tag v0.3.37 is cut and pushed, which is the only trigger of build-release.yml;
   3. that Build Release run concludes green across the whole platform matrix;
   4. scripts/check-release-published.py v0.3.37 reports it published as Latest — not draft, not prerelease — with the full asset set.

   Installing on the host is the host's own action and is not an acceptance item here.

   Closing this issue on the merge alone would assert a release that does not exist, which is exactly why its body kept the tag out of the PR.
5. how2how2how2-arch commented on Nov 4, 2026

   

   how2how2how2-arch

   on Nov 4, 2026

   CollaboratorAuthor

   More actions

   The tag is cut. The release is not published, so this issue stays open. Recording exactly what happened.

   The tag: annotated v0.3.37 on cd7ba6ad7f756b1576107aaa0c0036f539862ddc, pushed and unmoved since (same sha locally and remotely). It was cut only after all four prechecks passed: bump-version.py --check → all eight sources on 0.3.37; check-release-tag.py v0.3.37 → green; v0.3.37 absent on both sides; tree clean. The Test run on that exact commit was completed/success (both legs) before the tag was pushed.

   The build: run 41862508461 on cd7ba6ad, concluded failure, in two attempts.

   job	attempt 1	attempt 2
   verify-tag	success, 7s	success
   verify-credentials	cancelled, 15m02s, no runner, 0 steps	cancelled, 15m02s, no runner, 0 steps
   build ubuntu-24.04 x86_64	success, 10m12s	success, 11m08s
   build ubuntu-24.04-arm aarch64	success, 10m12s	success, 10m04s
   build windows-2025 x64	success, 14m53s	success, 11m41s
   build macos-15 arm64	success, 8m25s	success, 8m12s
   release	skipped	skipped

   So all four platform artifacts were produced in both attempts — 414 MB Windows, 141 MB macOS, 263 MB and 244 MB Linux — and release never ran, because a cancelled job in the run leaves it skipped. gh release view v0.3.37 answers "release not found", and scripts/check-release-published.py v0.3.37 reports FAULT with rc 1.

   The failing leg: verify-credentials. It requests a macos-15 runner and never acquired one: zero steps executed, no runner assigned, cancelled at exactly 15m02s on both attempts. Other macos-15 jobs in the same runs did acquire runners within minutes (the macOS build job started 11 minutes after the cancellation and finished in about 8), so this is specific to that job rather than to macOS capacity as a whole. The rerun reproduced it exactly, which is why a third attempt is not worth spending: the outcome is deterministic, not a flake.

   What it leaves, and what would finish it:

   • A release build whose verify-credentials job actually acquires a runner, so the four built artifacts reach release and a v0.3.37 release object exists as Latest with the full asset set.
   • The tag must not be moved, deleted or re-cut. The same tag with a working build is the finish; a second tag would only spend another version number.
   • Since the job never ran, no credential verdict was reached. This says nothing about whether the notarization credentials are still accepted — that question is open, not answered.

   One diagnostic gap observed while reading this, filed here rather than as its own issue because the tracker already has two live subjects: check-release-published.py's remedy for this failure points at scripts/read-run-failure.py, and that tool answers no failed job in run 41862508461 - nothing to explain because neither job failed — one was cancelled and one skipped. A run whose only non-success work was cancelled cannot be explained by the tool the reading recommends.
6. how2how2how2-arch commented on Nov 4, 2026

   

   how2how2how2-arch

   on Nov 4, 2026

   CollaboratorAuthor

   More actions

   Third attempt, same result. Recording it because the number of identical attempts is the reading, not the repetition.

   gh run rerun 41862508461 --failed was fired again about three hours after the second attempt, on the chance that this was runner capacity that had since changed. verify-credentials was queued at 19:05:01, never acquired a runner, and was cancelled at 19:20:03 — 15m02s, exactly as in attempts 1 and 2 — while all four build legs then acquired macos-15/ubuntu-24.04/windows-2025 runners within four seconds of each other and succeeded. release was skipped again. The tag is still on cd7ba6ad and no release exists.

   So this is deterministic, not a flake, and it is not macOS capacity as a whole: the macOS build leg got a runner one minute later. The same verify-credentials job succeeded on 2026-11-03 in the v0.3.36 release (runner 1000013813, label macos-15), so the job's definition is not the variable either.

   What would finish this is unchanged: a verify-credentials job that acquires a runner, so the four built artifacts reach release under this same tag. No second tag.

   One thing this cycle did change, so the next attempt is cheaper to read: scripts/read-run-failure.py now explains a run that concluded failure with no failed job, naming the cancelled job, how long it held, and that no runner was ever assigned — where before it answered "nothing to explain". That is #2710 / #2711.
7. how2how2how2-arch commented on Nov 4, 2026

   

   how2how2how2-arch

   on Nov 4, 2026

   CollaboratorAuthor

   More actions

   Released. scripts/check-release-published.py v0.3.37 reads:

   OK: v0.3.37 built green and is published -- not a draft, not a prerelease, 11 asset(s)
   

   and GitHub's Latest is v0.3.37.

   • build run 41862508461, attempt 4, completed/success
   • tag v0.3.37 (annotated object caec3bac, commit cd7ba6ad)
   • 11 assets: the two AppImages each with its .zsync, the two Linux .run/.tar.gz pairs,
     and the macOS .pkg

   The three attempts before this one failed identically, and the cause was never this tag
   or this tree. verify-credentials requested macos-15, was never assigned a runner
   (runner_name: null, zero steps executed), and was cancelled at 15m02s; release is
   downstream of it, so it was skipped each time while all four builds succeeded. On attempt 4
   the same job was assigned a runner and held 11 seconds — 21:44:28Z to 21:44:39Z. So the
   notarization credentials were valid throughout, nothing in the repository changed between
   attempt 3 and attempt 4, and the block was runner-pool capacity for one pinned label. That
   is worth knowing the next time this job does not appear: a job that is never scheduled is
   indistinguishable from a repository fault unless the runner field is read.

   One fact stated plainly rather than left implied: v0.3.37 is cut at cd7ba6ad and does
   not contain #2709, which landed after the bump. A release carrying it needs its own version
   bump — a separate decision, not taken here.
8. how2how2how2-arch

   closed this as completedon Nov 4, 2026