You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Analyze the CI failures in the PR for the current branch and fix them, following the structured plan below.
8
8
9
-
Each time this prompt is triggered, assume you are starting fresh from the beginning of the process.
10
-
11
-
Do not stop a given execution until you have worked through all phases below.
12
-
13
9
## Phase 0: Validate
14
10
15
-
1. Verify we're not on a protected branch: `git branch --show-current` should not be `main`
16
-
2. Check that the branch is up-to-date with remote: `git fetch && git status` - exit if `git status` reports the branch is `behind` or has `diverged` from remote.
17
-
3. Get the current branch name using `git branch --show-current`
18
-
4. Find the PR for this branch using `gh pr list --head <branch-name> --json number,title` and extract the PR number
19
-
5. Use `gh pr view <pr-number> --json statusCheckRollup --jq '.statusCheckRollup[] | select(.conclusion == "FAILURE") | {name: .name, detailsUrl: .detailsUrl, databaseId: .databaseId}'` to get the list of all failed CI jobs
20
-
6.**Ignore aggregate/rollup checks** like `required-status-check` — they fail if and only if some real underlying check fails, so fixing the real checks resolves them automatically. Do not spend effort downloading their logs.
21
-
7. Check if there are actually CI failures to fix - if all jobs passed (after filtering rollups), exit early
22
-
8.**Trivial-failure fast path**: if there is exactly one failing job with an obvious single root cause (e.g., one markdownlint rule, one spotless violation, one known-flaky infra error), skip Phases 1-2 entirely — fix directly, validate, commit. The CI-PLAN.md / `.git/info/exclude` machinery is overhead for a 2-line fix.
11
+
1. Verify we're not on a protected branch: `git branch --show-current` should not be `main`.
12
+
2. Check the branch is up-to-date: `git fetch && git status` — exit if `behind` or `diverged`.
13
+
3. Find the PR and its failed jobs:
14
+
```
15
+
BRANCH=$(git branch --show-current)
16
+
PR=$(gh pr list --head "$BRANCH" --json number --jq '.[0].number')
4.**Ignore aggregate/rollup checks** like `required-status-check` — fixing the real underlying checks resolves them automatically.
21
+
5. If all remaining jobs passed, exit early.
22
+
6.**Trivial-failure fast path**: if there is exactly one failing job with an obvious single root cause (e.g., one markdownlint rule, one spotless violation, one known-flaky infra error), skip Phases 1–2 — fix directly, validate, commit.
23
23
24
24
## Phase 1: Gather Information
25
25
26
-
**Phase 1 is for gathering raw log data and identifying failed tasks.**
27
-
**Allowed in Phase 1: downloading logs, grepping logs for error context, listing failed tasks. You may also read source files when strictly needed to classify a failure as real vs. flaky/infra.**
28
-
**Not allowed in Phase 1: editing code, or designing / planning fixes. Defer fix design to Phase 3.**
26
+
**Phase 1 is only for gathering raw log data and identifying failed tasks.** You may read source files when needed to classify a failure as real vs. flaky/infra. Do not edit code or design fixes yet.
29
27
30
-
### Working directory discipline
28
+
### Identify failing jobs to sample
31
29
32
-
- Always `cd` back to the repository root before running any `git`, `gh pr`, or `./gradlew` command. Log downloads in `/tmp` put the shell outside the repo and subsequent `git` commands will fail with `fatal: not a git repository`.
33
-
- Prefer one-shot invocations: `(cd /tmp && <download command>)` in a subshell, so the outer shell's cwd is preserved.
30
+
-**Ignore pure duplicates** that only differ by matrix parameters inside parentheses (e.g., `common / test0 (8, hotspot, indy false)` vs `(11, hotspot, indy false)`).
31
+
-**Do sample axes that plausibly change behavior**: different JDK majors, indy true vs false, `-deny-unsafe` / security-manager variants, latest-deps vs pinned. One representative per meaningfully distinct axis.
32
+
-**Flaky / infra failures**: network timeouts, cache misses, runner OOM, or anything clearly unrelated to PR code — note in `/tmp/ci-plan.md` under "Notes" and do not invent a code fix.
34
33
35
-
### Prevent CI-PLAN.md from being committed
34
+
### Download logs
36
35
37
-
Before creating `CI-PLAN.md`, add it to the repo-local ignore list so it can't be accidentally staged:
36
+
Use the REST API (more reliable than `gh run view --log-failed`, which on Windows/Git Bash sometimes fails or silently produces a 0-byte file):
1. Get repository info: `gh repo view --json owner,name`
47
-
2. Identify unique failing jobs:
48
-
-**Ignore pure duplicates** that only differ by matrix parameters inside parentheses (e.g., `common / test0 (8, hotspot, indy false)` vs `(11, hotspot, indy false)`).
49
-
-**Do sample axes that plausibly change behavior**: different JDK majors, indy true vs false, any `-deny-unsafe` / security-manager variants, and latest-deps vs pinned. Grab one representative per meaningfully distinct axis, not just one per job name prefix.
50
-
-**Flaky / infra failures**: if a failure looks like a network timeout, cache miss, runner OOM, or anything clearly unrelated to PR code, note it in `CI-PLAN.md` under "Notes" and do not invent a code fix for it.
51
-
3. Download logs for the selected representatives. Two equally-valid options:
52
-
53
-
**On Windows/Git Bash, default to Option B.**`gh run view --log-failed` is unreliable on that platform — it sometimes fails with `stream error: stream ID 1; CANCEL; received from peer`, and sometimes silently exits 0 while producing a 0-byte file. If you do try Option A, always verify the output is non-empty (`wc -l`) and fall back to Option B if it is empty.
54
-
55
-
**Option A: `gh run view`** (avoids putting the token in process argv; preferred on Linux/macOS):
56
-
57
-
```
58
-
# For a single job's failing log only:
59
-
gh run view --job <job-id> --log-failed > /tmp/<job-name>.log
60
-
61
-
# Or all failed steps across the whole run in one file:
62
-
gh run view <run-id> --log-failed > /tmp/run-<run-id>-failed.log
63
-
```
64
-
65
-
**Option B: REST API** — required on Windows/Git Bash:
Use subshells (`(cd /tmp && …)`) for `/tmp` operations so the outer shell stays in the repo root. Do not pipe `gh auth token` through `xargs` (puts the token in argv).
73
46
74
-
Token safety:
75
-
- Do NOT pipe `gh auth token` through `xargs` — that places the token in `argv` where other local processes can see it.
76
-
- Inlining it via `-H "Authorization: token $(gh auth token)"` also exposes it in the `curl` process's `argv` (visible to `ps` on multi-user systems). Acceptable on a single-user dev box; avoid on shared machines.
47
+
### Extract errors
77
48
78
-
4. For each downloaded log, extract failed Gradle tasks and error context:
one fix will resolve all axes. Record the full list of failing jobs in
91
-
`CI-PLAN.md` but don't waste time downloading each one's log.
55
+
Large PRs often produce dozens of failures that all stem from a single upstream task (e.g., one `compileJava` failure cascades into every test matrix cell). After 2–3 representatives, if they all report the **same failed upstream Gradle task with identical error text**, stop sampling — one fix will resolve all axes. Record the full list in the plan but don't download each log.
92
56
93
-
### Searching the repo
57
+
##Phase 2: Create plan
94
58
95
-
Use `rg` (ripgrep) for repo-wide text searches. It respects `.gitignore` by
96
-
default, so `build/`, `.gradle/`, and similar generated directories are skipped
97
-
automatically. Plain `grep -r` / `grep -rn` will descend into those
98
-
directories and may hang on large builds. `git grep` is also acceptable.
99
-
100
-
## Phase 2: Create CI-PLAN.md
101
-
102
-
**ONLY:** Create the CI-PLAN.md file in the repository root with the following structure:
59
+
Create `/tmp/ci-plan.md` (outside the repo — no risk of accidental commit):
103
60
104
61
```markdown
105
62
# CI Failure Analysis Plan
106
63
107
64
## Failed Jobs Summary
108
65
- Job 1: <job-name> (job ID: <id>)
109
-
- Job 2: <job-name> (job ID: <id>)
110
66
...
111
67
112
68
## Unique Failed Gradle Tasks
113
69
114
70
-[ ] Task: <gradle-task-path>
115
71
- Seen in: <job-name-1>, <job-name-2>, ...
116
-
- Log files: /tmp/<file1>.log, /tmp/<file2>.log
117
-
118
-
-[ ] Task: <gradle-task-path>
119
-
- Seen in: <job-name-1>, <job-name-2>, ...
120
-
- Log files: /tmp/<file1>.log, /tmp/<file2>.log
72
+
- Log files: /tmp/<file1>.log, ...
121
73
122
74
## Suspected Flaky / Infra Failures (skipped)
123
75
- <job-name>: <reason>
124
76
125
77
## Notes
126
-
[Any patterns or observations about the failures]
78
+
[Patterns or observations]
127
79
```
128
80
129
81
## Phase 3: Fix Issues
130
82
131
-
**Important**: Do not commit `CI-PLAN.md` — it's only for tracking work during the session. Phase 1 already added it to `.git/info/exclude`; do not use `git add -A` or `git commit -a` (either could still pick it up if the ignore entry was missed).
132
-
133
-
### Gradle execution rules (repo-specific)
134
-
135
-
- Never pipe Gradle output through `grep`, `tail`, `head`, or any other command. Piping masks Gradle's exit code, so a failing build silently appears to succeed.
136
-
- Run Gradle with no timeout (`timeout 0`) and wait for completion — builds and tests can take several minutes.
137
-
- Never use `--rerun-tasks`. Use `--rerun` when a task must be forced to re-execute.
138
-
139
-
### Per-task workflow
140
-
141
-
Work through `CI-PLAN.md`, checking items off as you complete them. For each failed task:
83
+
Work through `/tmp/ci-plan.md`, checking items off. For each failed task:
142
84
143
85
- Analyze the failure using the logs (now you may open source files).
- Markdown lint failures: most `markdownlint`rules have no auto-fix \u2014 edit manually. `mise run lint:markdown` only validates; there is no `lint:markdown:fix` task.
- Test failures: run the whole module's test task (e.g., `./gradlew :instrumentation:module-name:javaagent:test`) rather than just the single failing test — related tests in the module often need fixing too.
151
-
- Verify the fix resolves the issue.
152
-
- Update the checkbox in `CI-PLAN.md`.
153
-
- Commit each logical fix as a **separate commit**:
154
-
- Use explicit pathspecs. **Put `-m` before `--`**, because everything after `--` is treated as a pathspec by git: `git commit -m "..." -- path/one path/two`.
155
-
- Note that `git mv` auto-stages the rename — don't re-run `git add` on the moved paths.
156
-
- If `git mv` or earlier edits have already staged unrelated changes, `git reset` first and stage only the files for the current logical fix.
157
-
- Do not commit `CI-PLAN.md`.
92
+
- Test failures: run the whole module's test task rather than just the single failing test — related tests often need fixing too.
93
+
- Commit each logical fix as a **separate commit** with explicit pathspecs. **Put `-m` before `--`** (everything after `--` is a pathspec): `git commit -m "..." -- path/one path/two`.
94
+
-`git mv` auto-stages the rename — don't re-run `git add` on moved paths.
95
+
- If unrelated changes are already staged, `git reset` first.
158
96
- Do not `git push` in this phase.
159
97
160
-
## Phase 4: Validate and Push
98
+
## Phase 4: Push
161
99
162
-
- Delete `CI-PLAN.md` (`rm -f CI-PLAN.md`) and confirm `git status` is clean of it.
163
-
- Push the changes with plain `git push`.
164
-
- Only use `git push -f` / `--force-with-lease` if you rewrote history during the session (rebase, amend, reorder). Additive fix commits do not require a force push.
165
-
- Provide a summary of:
166
-
- What failures were found (including any skipped as flaky/infra).
167
-
- What fixes were applied.
168
-
- Which commits were created.
100
+
`git push`, then summarize:
101
+
- What failures were found (including any skipped as flaky/infra).
0 commit comments