Skip to content

Commit ec7fbb2

Browse files
msimacekmsimacek
committed
Refactor rota skills
1 parent fa890b9 commit ec7fbb2

5 files changed

Lines changed: 224 additions & 143 deletions

File tree

‎.agents/skills/github-pr-mirror/SKILL.md‎

Lines changed: 13 additions & 76 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
22
name: github-pr-mirror
3-
description: Mirror an external GitHub pull request into the internal GraalPython Bitbucket review flow, including OCA label checks, Jira creation or reuse, preserving PR commits, pre-commit cleanup, Bitbucket PR creation, Graal Bot task handling, and gate follow-up.
3+
description: Mirror an external GitHub pull request into the internal GraalPython Bitbucket review flow, including OCA label checks, Jira creation or reuse, preserving PR commits, pre-commit cleanup, and handoff to the shared GraalPython Bitbucket PR flow for PR creation, Graal Bot tasks, gates, and fixes.
44
---
55

66
# GitHub PR Mirror
@@ -12,8 +12,7 @@ This workflow intentionally preserves the original GitHub PR commits. Do not reb
1212
## Companion Skills
1313

1414
- Use the `jira` skill when creating or transitioning Jira issues.
15-
- Use the `bitbucket` skill when creating the Bitbucket PR or managing comments/tasks.
16-
- Use the `buildbot` skill when starting, watching, or investigating gates.
15+
- Use the `graalpython-bitbucket-pr` skill after the mirror branch is ready, to create the Bitbucket PR, handle Graal Bot tasks, start/watch gates, and fix or report gate failures.
1716

1817
## Inputs
1918

@@ -129,80 +128,18 @@ git commit -m "[GR-<ID>] Apply pre-commit fixes for GitHub PR#<PR_NUMBER>"
129128

130129
Only commit mechanical pre-commit output here. If pre-commit reveals non-mechanical problems, fix them in a separate follow-up commit when trivial; otherwise stop and ask the user.
131130

132-
### 5. Push to Bitbucket and create the PR
131+
### 5. Create the Bitbucket PR and follow gates
133132

134-
Push the branch to the Bitbucket remote:
133+
Use the `graalpython-bitbucket-pr` skill with these inputs:
134+
- Source branch: `github-pr/<PR_NUMBER>`
135+
- Bitbucket remote: `<BITBUCKET_REMOTE>`
136+
- Target branch: `<TARGET_BRANCH>`
137+
- Title: `[<JIRA_KEY>] GitHub PR#<PR_NUMBER>: <PR_TITLE>`
138+
- Description: `Mirrors GitHub <PR_URL> for internal review.`
139+
- Project/repository: `G` / `graalpython`
140+
- Reviewers: repo-level default reviewers
135141

136-
```bash
137-
git push <BITBUCKET_REMOTE> github-pr/<PR_NUMBER>
138-
```
139-
140-
Create the Bitbucket PR with default reviewers (listed in repo-level AGENTS.md):
141-
142-
```bash
143-
gdev-cli bitbucket create-pr \
144-
-p G \
145-
-r graalpython \
146-
-fb github-pr/<PR_NUMBER> \
147-
-tb <TARGET_BRANCH> \
148-
-t "[<JIRA_KEY>] GitHub PR#<PR_NUMBER>: <PR_TITLE>" \
149-
-rv "<REVIEWERS>" \
150-
-d "Mirrors GitHub <PR_URL> for internal review." \
151-
--gate
152-
```
153-
154-
Capture and print the Bitbucket PR URL. If `--gate` is not accepted or fails transiently, create the PR first, then start gates with:
155-
156-
```bash
157-
gdev-cli buildbot start-gate -p G -r graalpython -pr <BITBUCKET_PR_ID>
158-
```
159-
160-
### 6. Handle Graal Bot comments and tasks
161-
162-
Wait about 30 seconds after PR creation, then list comments and tasks:
163-
164-
```bash
165-
gdev-cli bitbucket comment list -p G -r graalpython -pr <BITBUCKET_PR_ID> --all --json
166-
gdev-cli bitbucket task list -p G -r graalpython -pr <BITBUCKET_PR_ID> --json
167-
```
168-
169-
For tasks or comments authored by Graal Bot:
170-
- Resolve tasks that are clearly administrative and already satisfied by this mirror workflow.
171-
- Changelog tasks are normally resolvable for bugfixes or small compatibility additions. Ask the user before resolving them for user-facing API/option changes or large features.
172-
173-
Resolve a task only when justified:
174-
175-
```bash
176-
gdev-cli bitbucket task resolve -p G -r graalpython -pr <BITBUCKET_PR_ID> -cm <COMMENT_ID>
177-
```
178-
179-
### 7. Watch gates
180-
181-
Use sparse polling because full gates can take about an hour. Prefer structured output for status decisions:
182-
183-
```bash
184-
gdev-cli buildbot gate-overview -p G -r graalpython -pr <BITBUCKET_PR_ID> --json
185-
gdev-cli buildbot gate-builds -p G -r graalpython -pr <BITBUCKET_PR_ID> --json
186-
```
187-
188-
Human-readable output is fine for reporting, but avoid parsing it when JSON is available.
189-
190-
Suggested cadence:
191-
- First check after PR creation and bot handling.
192-
- Then every 10 minutes while many jobs are running.
193-
- When fewer than about 5 jobs remain, poll every 5 minutes.
194-
- There's no need to send progress updates while gates are still running. Poll silently
195-
- If there are failures, stop polling and move to fixing/reporting the failure.
196-
197-
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.
198-
199-
If gates fail:
200-
- Inspect failing build logs with the `buildbot` skill.
201-
- Fix trivial issues yourself, such as style output, generated pre-commit fallout, missing `@TruffleBoundary`, obvious test-selector mistakes, or small import/order problems.
202-
- Commit fixes on top of the mirrored branch, push again, and restart or rerun gates as appropriate.
203-
- 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.
204-
205-
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.
142+
Let that skill create the PR, handle Graal Bot comments/tasks, start or verify gates, watch gates, and fix or report failures.
206143

207144
## Final Report
208145

@@ -213,4 +150,4 @@ Always report:
213150

214151
## Guardrails
215152
- Don't comment on the github PR unless asked. Never mention the internal bitbucket/buildbot/etc URLs in comments on github.
216-
- Do not stop monitoring the gates after they are created until they finish, fail, or become blocked by tooling. Sleep in 10 minute intervals by default.
153+
- After handing off to `graalpython-bitbucket-pr`, do not stop monitoring the gates until they finish, fail, or become blocked by tooling.

‎.agents/skills/graalpython-bitbucket-pr/SKILL.md‎

Lines changed: 124 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,124 @@
1+
---
2+
name: graalpython-bitbucket-pr
3+
description: Create or continue a GraalPython Bitbucket pull request and drive it through Graal Bot tasks, gate start, gate monitoring, failure investigation, fixes, pushes, and gate reruns. Use after a branch is ready for internal GraalPython review, or when an automation command has already created the PR and the remaining work is task cleanup and gate follow-up.
4+
---
5+
6+
# GraalPython Bitbucket PR
7+
8+
## Overview
9+
Create or continue a GraalPython Bitbucket PR, resolve administrative Graal Bot tasks, start or verify gates, watch gates, and fix or report failures.
10+
11+
## Companion Skills
12+
- Use the `bitbucket` skill for PR creation, comments, and tasks.
13+
- Use the `buildbot` skill for starting, watching, rerunning, and investigating gates.
14+
15+
## Inputs
16+
Required for new PRs:
17+
- Source branch already pushed or ready to push.
18+
- Target branch.
19+
- PR title.
20+
- PR description.
21+
- Jira key in the PR title.
22+
23+
Required for existing PRs:
24+
- Bitbucket PR ID or URL.
25+
26+
Defaults:
27+
- Project/repository: `G` / `graalpython`.
28+
- Reviewers: use the repo-level default reviewers unless the caller supplies a different list.
29+
- Target branch: master
30+
31+
## Workflow
32+
33+
### 1. Push and create the PR, if needed
34+
35+
If the source branch is not pushed yet:
36+
37+
```bash
38+
git push <BITBUCKET_REMOTE> <SOURCE_BRANCH>
39+
```
40+
41+
Create the Bitbucket PR:
42+
43+
```bash
44+
gdev-cli bitbucket create-pr \
45+
-p G \
46+
-r graalpython \
47+
-fb <SOURCE_BRANCH> \
48+
-tb <TARGET_BRANCH> \
49+
-t "<PR_TITLE>" \
50+
-rv "<REVIEWERS>" \
51+
-d "<PR_DESCRIPTION>" \
52+
--gate
53+
```
54+
55+
Capture the Bitbucket PR URL and ID. If `--gate` is not accepted or fails transiently, create the PR first, then start gates with:
56+
57+
```bash
58+
gdev-cli buildbot start-gate -p G -r graalpython -pr <BITBUCKET_PR_ID>
59+
```
60+
61+
If the PR already exists, capture the PR URL and ID, then continue with task handling and gate checks.
62+
63+
### 2. Handle Graal Bot comments and tasks
64+
65+
Wait about 15 seconds after PR creation, then list comments and tasks:
66+
67+
```bash
68+
gdev-cli bitbucket comment list -p G -r graalpython -pr <BITBUCKET_PR_ID> --all --json
69+
gdev-cli bitbucket task list -p G -r graalpython -pr <BITBUCKET_PR_ID> --json
70+
```
71+
72+
For tasks or comments authored by Graal Bot:
73+
- Resolve tasks that are clearly administrative and already satisfied by the PR workflow.
74+
- There should be a task regarding changelog. Changelog items are usually not needed for bugfixes and compatibility improvements.
75+
They are needed for added context options, changed public API's in `polyglot` module or large features. If a changelog item is needed
76+
but not present, suggest one and notify the user.
77+
78+
Resolve a task only when justified:
79+
80+
```bash
81+
gdev-cli bitbucket task resolve -p G -r graalpython -pr <BITBUCKET_PR_ID> -cm <COMMENT_ID>
82+
```
83+
84+
### 3. Watch gates
85+
86+
Use sparse polling because full gates can take about an hour. Prefer structured output for status decisions:
87+
88+
```bash
89+
gdev-cli buildbot gate-overview -p G -r graalpython -pr <BITBUCKET_PR_ID> --json
90+
gdev-cli buildbot gate-builds -p G -r graalpython -pr <BITBUCKET_PR_ID> --json
91+
```
92+
93+
Human-readable output is fine for reporting, but avoid parsing it when JSON is available.
94+
95+
Suggested cadence:
96+
- First check after PR creation and bot handling.
97+
- Then every 10 minutes while many jobs are running.
98+
- When fewer than about 5 jobs remain, poll every 5 minutes.
99+
- Poll silently while gates are still running.
100+
- If there are failures, try to diagnose them as soon as they appear.
101+
102+
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.
103+
104+
### 4. Fix or report gate failures
105+
106+
If gates fail:
107+
- Inspect failing build logs with the `buildbot` skill.
108+
- Fix trivial issues yourself, such as style output, generated pre-commit fallout, missing `@TruffleBoundary`, obvious test-selector mistakes, or small import/order problems.
109+
- Commit fixes on top of the PR branch, push again, and restart or rerun gates as appropriate.
110+
- 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.
111+
- 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.
112+
- Typical signs of a transient failure:
113+
- Infrastructure issues in the worker setup, git checkout or cleanup
114+
- Single failed test on a single platform that succeeded on other platforms
115+
- Test failures in tests involving weakrefs, subprocesses or multi-threading in PRs that didn't touch those subsystems.
116+
117+
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.
118+
119+
## Final Report
120+
Always report:
121+
- Bitbucket PR URL
122+
- Gate status
123+
- Any unresolved failures or Graal Bot tasks
124+
- Any transient issues encountered, with links to failed builds

‎.agents/skills/graalpython-rota/SKILL.md‎

Lines changed: 0 additions & 67 deletions
This file was deleted.

‎.agents/skills/rota-check-periodic-jobs/SKILL.md‎

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
---
2+
name: rota-check-periodic-jobs
3+
description: Analyze recent GraalPy periodic job failure Jira tickets for ROTA. Use when asked to triage, summarize, or plan work for recent periodic-job-failures issues, including date-bounded Jira searches with gdev-cli, issue detail inspection, hypotheses, reproduction commands, and implementation order.
4+
---
5+
6+
# ROTA Periodic Job Check
7+
8+
## Overview
9+
Triage recent GraalPy periodic job failure Jira tickets and produce implementation-ready plans.
10+
11+
## Workflow
12+
1. Verify creator identity mapping:
13+
- Treat `ol-automation_ww` as Jira username `olauto`.
14+
- If a query returns zero results unexpectedly, test both identities, then keep `creator = olauto` once verified.
15+
16+
2. Filter to recent periodic job failures, excluding in-progress or closed issues:
17+
- Default to the last 14 days unless the user specifies otherwise.
18+
- Always state concrete start and end calendar dates in the response.
19+
```bash
20+
gdev-cli jira search --json --max 100 \
21+
-f key,summary,creator,created,status,labels,components,assignee \
22+
-jql "project = GR AND component = Python AND creator = olauto AND labels = periodic-job-failures AND created >= -14d AND status != Closed AND status != 'In Progress' ORDER BY created DESC"
23+
```
24+
25+
3. Fetch shortlisted issue details with `get-issue`:
26+
```bash
27+
gdev-cli jira get-issue --json -id GR-XXXX \
28+
| jq '{key, summary:.fields.summary, status:.fields.status.name, created:.fields.created, labels:.fields.labels, assignee:(.fields.assignee.name // null), description:.fields.description, comments:(.fields.comment.comments | map({author:.author.name, created, body}))}'
29+
```
30+
31+
4. Convert findings into an implementation-ready plan per issue:
32+
- Extract failing job name, error signature, and log clue.
33+
- Map probable source area in repo.
34+
- Propose the first verification command.
35+
- Define exit criteria to close the ticket.
36+
- Prepare a temporary git worktree per issue with branch naming based on Jira key plus a very short hyphenated description.
37+
38+
## Output Contract
39+
Return exactly:
40+
1. Query scope used: component, creator, time window, status filter.
41+
2. Count summary: total recent automation issues vs periodic failures.
42+
3. Issue list with key, created date, summary, and status.
43+
4. Per-issue plan with:
44+
- Hypothesis
45+
- First code locations to inspect
46+
- First reproducibility command
47+
- Exit criteria for closing ticket
48+
5. Recommended implementation order.
49+
50+
## Guardrails
51+
- State concrete dates for recency windows.
52+
- Prefer `--json` and explicit `-f` fields in searches.
53+
- Use `get-issue` only for shortlisted issues to keep output small.

‎.agents/skills/rota-update-import/SKILL.md‎

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
---
2+
name: rota-update-import
3+
description: Run the GraalPy ROTA import update workflow. Use when asked to refresh imports, create the standard Graal import update pull request, inspect generated commits, and hand off to the shared GraalPython Bitbucket PR flow for tasks, gates, and failure fixes.
4+
---
5+
6+
# ROTA Import Update
7+
8+
## Overview
9+
Execute the GraalPy ROTA import update workflow using the repo's automated command, then use the shared GraalPython Bitbucket PR workflow for post-creation tasks and gates.
10+
11+
## Companion Skills
12+
- Use the `graalpython-bitbucket-pr` skill after `mx python-update-import --rota` creates the PR, to handle Graal Bot tasks, start or verify gates, watch gates, and fix or report failures.
13+
14+
## Workflow
15+
1. Run the automated branch setup, import update, GitHub unittest-tag refresh, enterprise unittest-tag refresh, push, and standard PR creation:
16+
```bash
17+
mx python-update-import --rota
18+
```
19+
20+
2. If the command reports that `../graal-enterprise/graalpython-enterprise` is missing, stop and ask the user to provide that checkout.
21+
22+
3. Inspect the two generated commits and the created PR for plausibility:
23+
- Expect one import update commit.
24+
- Expect one combined unittest-tag update commit.
25+
- Expect mostly additions, not removals, in the combined unittest-tag commit.
26+
27+
4. Use the `graalpython-bitbucket-pr` skill in existing-PR mode with the PR created by `mx python-update-import --rota`.
28+
29+
5. Let that skill handle Graal Bot tasks, start or verify gates, watch gates, and fix or report failures.
30+
31+
## Guardrails
32+
- Use `mx python-update-import --rota`; do not manually reconstruct the standard ROTA sequence unless the command fails and the failure requires targeted recovery.
33+
- Preserve the automated commit structure unless there is a concrete reason to amend it.
34+
- When reporting status, include the branch name, PR link or ID, gate status, and any follow-up failures.

0 commit comments

Comments
 (0)