[JacobStephens2]

Summary

The release script now finishes when the release workflow run for the tag has succeeded, not when the tag is pushed.

 main
   finish_if_tagged            # was stop_if_tagged
-    "already tagged, nothing left to do"; exit 0
+    "already tagged"; wait_for_release; exit
   … bump, PR, CI wait, merge …
   push tag v<version>
+  wait_for_release
+    poll gh run list --workflow release.yml --event push --commit <merge>
+      not listed yet   → "waiting for the release workflow on v<version> to start"
+      listed           → "waiting for the release workflow at <run URL>"
+    until completed (current attempt, no overall timeout)
+    success → "released v<version> at <GitHub Release URL>"; exit 0
+    failure → names failed jobs + run URL, suggests `gh run rerun --failed <id>`,
+              tag left in place; exit 1

CI's run on main for the same merge commit is not waited for. The fake gh now models release workflow runs: not yet listed (hidden_polls), in progress (pending_polls), jobs, a rerun attempt (same databaseId), plus gh run view and gh release view. The README release section and the script header describe the new stopping point, exit codes and resume behaviour.

Evidence

• Before: the script's last line is release: tagged v0.2.0 on <sha> and pushed the tag and it exits 0. The new tests fail against the old script (9 of 41 in tests/release.rs), e.g. each_step_prints_a_progress_line_on_stderr: no "release: waiting for the release workflow at …/actions/runs/2".
  After: cargo test is all green, tests/release.rs 41 passed. New cases:
  • run listed only after 3 polls, then in progress for 2: waits and exits 0 with release: released v0.2.0 at …/releases/tag/v0.2.0 as its last line
  • failed run: exit 1, names custom-release-smoke / rocky, run URL and gh run rerun --failed <id>, tag still on the merge
  • CI on main for the merge in progress or failed: release still exits 0
  • rerun with the tag on the merge: waits for a running run; exits 0 with nothing pushed after success; exits 1 after failure; after the failed jobs were rerun, the new attempt's success counts

Merge Danger

Door: two-way

Maintainer tooling only. The release workflows don't change.

Blast Radius: releases

A release now takes about 7–8 minutes longer to exit. If the gh run list query ever mismatched the real run, the script would poll forever. Ctrl-C then leaves the release unaffected, because the tag has already been pushed. The query was checked against the real v0.5.0 run (36766380629).

Unaddressed findings

Standards

• The "did not succeed" rule is duplicated in release.sh (the awk in wait_for_workflow_runs and the jq in wait_for_release) and the poll loop repeats. Skipped: the two read different sources (gh api lines vs gh run view JSON), so a shared helper would have to span awk and jq for three conditions.
• The fake gh copies the script's jq strings, and run_view repeats the filter in Python. Skipped: the fake already matches --jq strings exactly (LATEST_RUN_LINE, WORKFLOW_RUN_LINES). That is how it fails loudly when a query changes.

Spec

• A transient gh failure during the wait ends the script (exit 1) without the rerun hint. Skipped: the spec doesn't ask for retries, and rerunning the script resumes the wait.

Closes #211

🤖 Generated with Claude Code