Commit b9bd02b
authored
Reverts: #4171
Initiated by: yjbanov
Reason for reverting: the new code seems to be landing on red check runs
Original PR Author: yjbanov
Reviewed By: {jtmcdole}
This change reverts the following previous change:
Implement the new break glass behavior for the monorepo world.
Fixes flutter/flutter#159898
Fixes flutter/flutter#132811
Below is an updated copy of flutter/flutter#159898 (comment):
# Pull request
## Two-state Merge Queue Guard
The guard can only be in two states:
- **Pending** (yellow): this is the initial state, and the guard stays in this state for as long as the pull request is not allowed to enter the merge queue.
- **Success** (green): the guard enters this state when the infra decides that the PR is allowed to enter the merge queue.
The state can only go from pending to success. There are no other state transitions.
## Deciding when the guard goes green
Going from pending to green is the only transition we need to worry about. This is how we decide it:
- **Normal case**: the normal workflow for landing a PR is for all the checks to go green. Once this happens, Cocoon closes the guard (by making it green). This will allow the `autosubmit` label to enqueue the PR, and it will allow the author to press "Merge When Ready".
- **Emergency case**: the a PR must be landed despite failing checks (typically on a red tree status). The author adds the `emergency` label. Cocoon immediately unlocks the guard, ignoring any pending or failed checks. In conjunction with the `autosubmit` label, Cocoon will also automatically enqueue the PR after all tests pass even if the tree status is red. With an `emergency` Cocoon will also let the PR to jump the queue. However, if the PR must be landed right away, the author can use the "Merge When Ready" button manually as soon as Cocoon unlocks the merge guard.
## Explainer
The above system makes everything simpler. There are fewer states (just pending and success), fewer transitions (just pending => success), and fewer situations to consider (normal and emergency). We don't need to do anything special w.r.t. the guard for the purposes of retrying failed flaky tests. It simply stays pending while the author is doing whatever is necessary to make the PR green enough to land: push fixes, retry check runs, rebase, get approvals, etc.
Importantly, it covers all situations we need to handle in PR management.
### Why not have a third "failed" state?
The guard's job is not to tell you whether any tests are failing. You can already tell which tests are failing by looking at the status of respective check runs (this may change in the future, but when that time comes we'll find a new visual cue). The guard's job is only to tell you whether your PR is allowed to be enqueued. Permission to proceed never "fails". It's either granted (green), or not yet granted (pending). Once granted the PR is typically enqueued or landed immediately, so performing any other state transitions after green is mostly meaningless. Green is the final state of the guard, that's all.
The other reason for keeping the guard in two states is for simpler state management. Once green, the PR can immediately be enqueued. There's no transition from pending to failed, from failed to pending, or from failed to green. We can remove some of the existing Cocoon code around this, and we don't have to add anything new to support normal and emergency PR landing.
# Merge group
There are two possible outcomes for a merge group:
- **Land**: all check runs are green => Cocoon completes the merge guard as success and GitHub lands the merge group.
- **Fail**: some check runs failed => Cocoon fails the merge guard and GitHub pulls the merge group (and the corresponding PR) out of the queue.
1 parent 932b91b commit b9bd02b
File tree
22 files changed
+450
-872
lines changed- app_dart
- lib/src
- model/firestore
- service
- test
- model/firestore
- request_handlers/github
- service
- src/datastore
- auto_submit
- lib
- requests
- service
- validations
- test
- requests
- service
- src/service
- validations
22 files changed
+450
-872
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
88 | 88 | | |
89 | 89 | | |
90 | 90 | | |
91 | | - | |
92 | | - | |
| 91 | + | |
93 | 92 | | |
94 | 93 | | |
95 | 94 | | |
| |||
111 | 110 | | |
112 | 111 | | |
113 | 112 | | |
114 | | - | |
115 | 113 | | |
116 | 114 | | |
117 | | - | |
118 | 115 | | |
119 | 116 | | |
120 | 117 | | |
| |||
149 | 146 | | |
150 | 147 | | |
151 | 148 | | |
152 | | - | |
153 | | - | |
154 | | - | |
155 | | - | |
156 | | - | |
157 | | - | |
158 | 149 | | |
159 | 150 | | |
160 | | - | |
| 151 | + | |
161 | 152 | | |
162 | 153 | | |
163 | 154 | | |
| |||
166 | 157 | | |
167 | 158 | | |
168 | 159 | | |
169 | | - | |
170 | | - | |
171 | 160 | | |
172 | 161 | | |
173 | 162 | | |
| |||
218 | 207 | | |
219 | 208 | | |
220 | 209 | | |
221 | | - | |
| 210 | + | |
222 | 211 | | |
223 | 212 | | |
224 | 213 | | |
| |||
228 | 217 | | |
229 | 218 | | |
230 | 219 | | |
231 | | - | |
232 | | - | |
233 | | - | |
234 | | - | |
235 | | - | |
236 | | - | |
237 | | - | |
238 | | - | |
239 | | - | |
240 | 220 | | |
241 | 221 | | |
242 | 222 | | |
| |||
259 | 239 | | |
260 | 240 | | |
261 | 241 | | |
262 | | - | |
263 | | - | |
264 | | - | |
265 | | - | |
266 | | - | |
267 | | - | |
268 | | - | |
269 | | - | |
270 | | - | |
271 | 242 | | |
272 | 243 | | |
273 | 244 | | |
| |||
372 | 343 | | |
373 | 344 | | |
374 | 345 | | |
375 | | - | |
376 | | - | |
377 | 346 | | |
378 | 347 | | |
379 | 348 | | |
380 | 349 | | |
381 | 350 | | |
382 | 351 | | |
383 | | - | |
384 | | - | |
385 | 352 | | |
386 | 353 | | |
387 | 354 | | |
| |||
399 | 366 | | |
400 | 367 | | |
401 | 368 | | |
402 | | - | |
403 | | - | |
404 | | - | |
405 | | - | |
406 | | - | |
407 | | - | |
408 | | - | |
409 | | - | |
410 | | - | |
411 | | - | |
412 | | - | |
413 | | - | |
414 | | - | |
| 369 | + | |
415 | 370 | | |
416 | 371 | | |
417 | | - | |
418 | | - | |
| 372 | + | |
419 | 373 | | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
32 | 32 | | |
33 | 33 | | |
34 | 34 | | |
35 | | - | |
36 | | - | |
| 35 | + | |
37 | 36 | | |
38 | 37 | | |
39 | 38 | | |
40 | 39 | | |
41 | | - | |
42 | | - | |
43 | | - | |
44 | | - | |
45 | | - | |
46 | | - | |
47 | | - | |
48 | | - | |
49 | | - | |
50 | | - | |
51 | | - | |
52 | | - | |
53 | | - | |
54 | | - | |
55 | | - | |
56 | | - | |
57 | | - | |
58 | | - | |
59 | | - | |
60 | | - | |
61 | | - | |
62 | | - | |
63 | | - | |
64 | | - | |
65 | | - | |
66 | 40 | | |
67 | 41 | | |
68 | 42 | | |
| |||
176 | 150 | | |
177 | 151 | | |
178 | 152 | | |
| 153 | + | |
179 | 154 | | |
180 | 155 | | |
181 | 156 | | |
| |||
0 commit comments