PR Gate Check

Overview

Use this workflow when asked for gate status of a PR. Usually the builds are tied to a merge commit generated on Bitbucket, so this skill goes through finding the remote merge commit.

Workflow

1. Get PR commits and identify PR head commit (first commit in gdev-cli bitbucket commits output):

gdev-cli bitbucket commits --project=G --repo=graalpython --pullrequest=<PR_ID> --all --json

2. Fetch refs and locate merge commit whose parent includes PR head:

git ls-remote origin 'refs/pull-requests/<PR_ID>/*'
git fetch --no-tags origin '+refs/heads/*:refs/remotes/origin/*' --prune
git rev-list --all --parents | rg ' <PR_HEAD_SHA>( |$)'

Pick the merge commit where one parent is <PR_HEAD_SHA> and the other is the target branch tip at merge time.

If you cannot find it this way, another heuristic is to take the branch name and append _gate - that usually has the merge commit we want as tip.

3. Check builds on that merge commit:

gdev-cli bitbucket get-builds --commit=<MERGE_SHA> --all --format=key,state,url

4. Separate root failures from fan-out failures:

• FAILED + /builders/.../builds/... URL: executed failed build (root failure candidate).
• FAILED + build_request?brid= URL: usually not-run/downstream due to earlier failure.

5. Inspect root failed build logs and extract exact failing test/error:

• Open build URL and Run executor stdio log.
• Capture failing test id, traceback/assertion, and command context.

6. Report back:

• PR head SHA
• merge SHA + parents (target parent + PR parent)
• build summary counts
• root cause failure(s)
• fix options and next action question

Output Template

1. PR head: <sha>
2. Gate merge commit: <sha> (parent1=<target_sha>, parent2=<pr_sha>)
3. Builds: <total> total, <success> successful, <failed> failed
4. Root failure(s):

• <build key>: <error summary>
• <failing test/path>
• <build url>

5. Proposed fixes: short list
6. Ask user what to do next.

Guardrails

• Do not conclude from PR commit statuses alone; always resolve and inspect merge-commit builds.
• If many builds are failed but only one executed failure exists, treat that one as primary cause.
• Keep proposed fixes minimal and scoped to observed failure.