also looking at this
feat(ci): let @buddy fix-ci find the run a comment cannot name
#1413
10 files
+697
-121
| @@ -87,8 +87,24 @@ that job's log. The workflow generated by `buddy setup` wires this up: when a | ||
| 87 | 87 | run on a Buddy branch fails, the `fix-ci` job reads its log and reports back on |
| 88 | 88 | the pull request. |
| 89 | 89 | |
| 90 | A comment cannot say *which* run failed, so `@buddy fix-ci` in a thread replies | |
| 91 | pointing at that job rather than guessing. | |
| 90 | ## From a comment | |
| 91 | ||
| 92 | `@buddy fix-ci` on a pull request finds the run itself: the newest failing run | |
| 93 | at the *current* head commit. Restricted to the head deliberately — a branch | |
| 94 | keeps its old runs, and diagnosing one from three pushes ago would produce a | |
| 95 | confident report about a failure somebody already fixed. If nothing at the head | |
| 96 | is red, it says so rather than reaching further back. | |
| 97 | ||
| 98 | What it does from there is bounded by where it runs. Answering a comment happens | |
| 99 | on the default branch, not the pull request's, so a lock-file rewrite or an | |
| 100 | agent edit would land on the wrong tree entirely. From a comment Buddy will: | |
| 101 | ||
| 102 | - classify the failure and post the diagnosis | |
| 103 | - tell you whether the base branch already fails the same way | |
| 104 | - re-run a flake, which is an API call and needs no checkout | |
| 105 | ||
| 106 | and it will name the repair it *cannot* apply rather than staying quiet about | |
| 107 | it. The `fix-ci` job below does check out the branch, and repairs there. | |
| 92 | 108 | |
| 93 | 109 | ### Whose failure is it |
| 94 | 110 | |