Graalpython Bitbucket Pr

GraalPython Bitbucket PR

Overview

Create or continue a GraalPython Bitbucket PR, resolve administrative Graal Bot tasks, start or verify gates, watch gates, and fix or report failures.

Companion Skills

• Use the bitbucket skill for PR creation, comments, and tasks.
• Use the buildbot skill for starting, watching, rerunning, and investigating gates.

Inputs

Required for new PRs:

• Source branch already pushed or ready to push.
• Target branch.
• PR title.
• PR description.
• Jira key in the PR title.

Required for existing PRs:

• Bitbucket PR ID or URL.

Defaults:

• Project/repository: G / graalpython.
• Reviewers: use the repo-level default reviewers unless the caller supplies a different list.
• Target branch: master

Workflow

1. Push and create the PR, if needed

If the source branch is not pushed yet:

git push <BITBUCKET_REMOTE> <SOURCE_BRANCH>

Create the Bitbucket PR:

gdev-cli bitbucket create-pr \
  -p G \
  -r graalpython \
  -fb <SOURCE_BRANCH> \
  -tb <TARGET_BRANCH> \
  -t "<PR_TITLE>" \
  -rv "<REVIEWERS>" \
  -d "<PR_DESCRIPTION>" \
  --gate

Capture the Bitbucket PR URL and ID. If --gate is not accepted or fails transiently, create the PR first, then start gates with:

gdev-cli buildbot start-gate -p G -r graalpython -pr <BITBUCKET_PR_ID>

If the PR already exists, capture the PR URL and ID, then continue with task handling and gate checks.

2. Handle Graal Bot comments and tasks

Wait about 15 seconds after PR creation, then list comments and tasks:

gdev-cli bitbucket comment list -p G -r graalpython -pr <BITBUCKET_PR_ID> --all --json
gdev-cli bitbucket task list -p G -r graalpython -pr <BITBUCKET_PR_ID> --json

For tasks or comments authored by Graal Bot:

• Resolve tasks that are clearly administrative and already satisfied by the PR workflow.
• There should be a task regarding changelog. Changelog items are usually not needed for bugfixes and compatibility improvements. They are needed for added context options, changed public API's in polyglot module or large features. If a changelog item is needed but not present, suggest one and notify the user.

Resolve a task only when justified:

gdev-cli bitbucket task resolve -p G -r graalpython -pr <BITBUCKET_PR_ID> -cm <COMMENT_ID>

3. Watch gates

Use sparse polling because full gates can take about an hour. Prefer structured output for status decisions:

gdev-cli buildbot gate-overview -p G -r graalpython -pr <BITBUCKET_PR_ID> --json
gdev-cli buildbot gate-builds -p G -r graalpython -pr <BITBUCKET_PR_ID> --json

Human-readable output is fine for reporting, but avoid parsing it when JSON is available.

Suggested cadence:

• First check after PR creation and bot handling.
• Then every 10 minutes while many jobs are running.
• When fewer than about 5 jobs remain, poll every 5 minutes.
• Poll silently while gates are still running.
• If there are failures, try to diagnose them as soon as they appear.

Treat the gate as successful only when there are no running and no failed gate builds. Other PR vetoes, such as reviewer approval, merge queue state, or GitHub mirroring consideration, are not gate failures.

4. Fix or report gate failures

If gates fail:

• Inspect failing build logs with the buildbot skill.
• Fix trivial issues yourself, such as style output, generated pre-commit fallout, missing @TruffleBoundary, obvious test-selector mistakes, or small import/order problems.
• Commit fixes on top of the PR branch, push again, and restart or rerun gates as appropriate.
• Report non-trivial semantic failures, broad compatibility failures, or failures that require product judgment to the user with the Bitbucket PR URL, Jira key, and concise failure summary.
• Many gate failures are transient. Use your judgement to determine if a failure might be transient and if it's the case, restart the gate and go back to polling.
• Typical signs of a transient failure:
  • Infrastructure issues in the worker setup, git checkout or cleanup
  • Single failed test on a single platform that succeeded on other platforms
  • Test failures in tests involving weakrefs, subprocesses or multi-threading in PRs that didn't touch those subsystems.

Do not leave a long sleep process running after an interruption or handoff. If monitoring is interrupted, clean up any background sleep/polling process you started, then resume with a fresh status check.

Final Report

Always report:

• Bitbucket PR URL
• Gate status
• Any unresolved failures or Graal Bot tasks
• Any transient issues encountered, with links to failed builds