Reverts "Break glass v2 (#4171)" #4175
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
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:
autosubmitlabel to enqueue the PR, and it will allow the author to press "Merge When Ready".emergencylabel. Cocoon immediately unlocks the guard, ignoring any pending or failed checks. In conjunction with theautosubmitlabel, Cocoon will also automatically enqueue the PR after all tests pass even if the tree status is red. With anemergencyCocoon 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: