Skip to content

Fix checks not updating on rebuild; handle GitHub's own re-run webhooks - #375

Open
alexreinking wants to merge 1 commit into
masterfrom
alexreinking/rerun-checks
Open

alexreinking wants to merge 1 commit into
masterfrom
alexreinking/rerun-checks

Conversation

@alexreinking

Copy link
Copy Markdown
Member

Summary

Two related bugs in the GitHub Checks API integration added in #373/#374:

  • Clicking Rebuild in the Buildbot Web UI after an intermittent failure left the check stuck on "failure". GitHubAppCheckPush.createStatus() looked up the most recent check run for a given name+sha and always PATCHed it, even if that run had already gone completed. On rebuild, the new build's "queued"/"in_progress" reports were patching the old, finished run backward, which isn't a transition GitHub expects. Now a check run is only reused (PATCHed) while it's still open; once completed, the next report creates a fresh check run, matching GitHub's own documented guidance for handling check_run.rerequested.
  • GitHub's own "Re-run" / "Re-run all jobs" buttons did nothing, since SafeGitHubEventHandler had no handler for the check_run/check_suite webhook events those buttons send (delivered via the halide-ci App's own webhook subscription, separate from the classic repo push/pull_request webhook). Added handlers for the rerequested action that resolve the check run's own details_url (Buildbot's own build URL) back to a builderid/build_number, then rebuild it via the same data-API path (rebuildBuildrequest) the Web UI's own Rebuild button uses. check_suite rerequests list the suite's check runs and rebuild each one that's ours (name starting with buildbot/), so "Re-run all jobs" covers every builder.

The halide-ci GitHub App's webhook has been reconfigured to point at Buildbot's existing /change_hook/github endpoint with the Checks events subscribed, so both fixes are live once this deploys.

Test plan

  • ruff check / ruff format --check
  • ty check --error-on-warning master/master.cfg master/custom_steps.py
  • bandit, codespell, vulture
  • buildbot checkconfig master
  • After deploy: trigger an intermittent failure, click Rebuild in the Buildbot UI, confirm the PR check goes back to green instead of staying failed
  • After deploy: click GitHub's own "Re-run" on a failed check, confirm Buildbot actually rebuilds it
  • After deploy: click "Re-run all jobs", confirm all builders rebuild

🤖 Generated with Claude Code

…GitHub re-run webhooks

An intermittent build failure followed by clicking "Rebuild" in the Buildbot
Web UI left the check stuck on "failure": GitHubAppCheckPush.createStatus()
patched the most recent check run for a given name+sha even after it had
already completed, but PATCHing a completed run's status back to
queued/in_progress isn't how GitHub expects reruns to be handled. Only reuse
a check run while it's still open; once it's completed, start a fresh one,
matching GitHub's own guidance for handling check_run.rerequested.

Separately, GitHub's own "Re-run"/"Re-run all jobs" buttons never reached
Buildbot at all, since SafeGitHubEventHandler had no handler for the
check_run/check_suite webhook events those buttons send. Add handlers for
the "rerequested" action that re-run the exact build(s) a check (run or
suite) points at, via the same data-API path the Buildbot Web UI's own
"Rebuild" button uses.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant