1657921 - Show a "merge candidate" indicator on pushes which can be merge candidates

Status: NEW

(Tree Management :: Treeherder: Frontend, enhancement)

Description

[Marco Castelluccio [:marco]]

We could show a "merge candidate" indicator on pushes for which we are sure we run everything and there are no failures.

A clear example of such a push is a full backstop with no failures. On full backstops we run everything by definition, so if there are no failures the push matches the definition of a good merge candidate.

Another example is an old push which run only part of the tests, with a set of children pushes which also run only parts of the tests. If when considering all of the pushes together all tests were run and there were no failures, the old push also matches the definition of a good merge candidate.

Comment 1

[Marco Castelluccio [:marco]]

The first one is relatively easy to implement.

The second is a little harder, but it is doable with mozci.

Comment 2

[Joel Maher ( :jmaher ) (UTC -8)]

it is near impossible to have no failures on a push, let alone one with all tests. The second example makes the most sense, but honestly for the sheriffing workflow it should be baked into treeherder- as we are looking to use mozci with pushhealth, could we create the functionality on a rolling basis for mozci and then have treeherder use it to get results?

Comment 3

[Andrew Halberstadt [:ahal]]

If we do the second route, I'd suggest we write a little cli script at first (maybe an adr recipe). Then figure out the UI/UX part afterwards. Sheriffs already run a lot of CLI scripts as part of their workflow, so even that would likely be useful to them.

Comment 4

[Andrew Halberstadt [:ahal]]

A thing to keep in mind is that we'll need to make sure the merge candidate is not in-between a regression and its backout. E.g:

Push 1 -> Causes M-bc1 regression
Push 2 -> M-bc1 does not run
Push 3 -> Backsout Push 1; M-bc1 is green

We'll need to be careful not to select Push 2 as the merge candidate there. Luckily mozci is already good at this kind of stuff :).

Comment 5

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Bug 1656465 (having all the tasks run on the merge candidate which are required to be successful on central) is more a scheduling question than exposing which pushes ran the rarely running tasks.

Regarding merge candidates, if you want to implement this, please focus to show which pushes ran the necessary tasks. Sheriffs sometimes use and adjacent push to merge if the merge candidate was affected by exactly one issue which either got fixed by the next push or started with the push (then the one before can be used).