Poll every publish with one request, so a long approval wait stays inside the token's quota

Merged
JE
13d ago
+24-16

Held: don't merge until Jeremy says so. This is the basecamp-sdk port of the polling fix in basecamp/fizzy-sdk#201, merged as basecamp/fizzy-sdk@0106610.

Problem. Since #975, wait-for-publishes waits up to 5.5 hours for the publishes, which need a reviewer's approval. Each poll runs gh run list --workflow once per release workflow, and each call costs about two API requests: one to resolve the workflow file, one to list its runs. Seven workflows polled every 30s come to about 1,680 requests an hour, and the GITHUB_TOKEN quota is 1,000 an hour. An approval wait longer than about 35 minutes runs out of quota, gh errors, and the job fails without a GitHub Release.

Change (.github/workflows/release-github.yml only):

  • Each poll makes one request: GET actions/runs?head_sha=$GITHUB_SHA&event=push&per_page=100. Each workflow's run is picked from that list by path, ignoring any @ref suffix, and head_branch == $TAG. event=push still excludes workflow_dispatch rehearsals on the same tag.

  • If listing fails, the job logs a warning and every workflow stays "waiting" until the next poll. A transient API error no longer ends a wait that can last hours.

  • The wait is timed with bash's SECONDS rather than by adding up the sleeps. A sleep counter leaves out the time each poll takes, so the loop could run past 5.5 hours and hit the job's 340-minute timeout before it reported. Same fix as hey-sdk f26a09b.

Request budget. 1 request per 30s poll is about 120 an hour, around 660 over the full 5.5-hour wait. That's 12% of the hourly quota.

Checked: actionlint is clean. I ran the jq matcher against a fixture: it picks the current tag's run over an older tag's run on the same workflow, matches a path carrying an @refs/tags/… suffix, and gives an empty result for a workflow with no run. Not yet run against a real tag.