1833439 - esr102 try push failing decision task

Status: RESOLVED DUPLICATE of bug 1694407

(Tree Management :: Treeherder, defect)

Description

[Mike Kaply [:mkaply]]

I have tried twice to push to the 102 ESR on tree herder, but it fails the decision task:

https://treeherder.mozilla.org/jobs?repo=try&revision=41617ce08cbf1c2951f474db0528d97f3f7c7405

https://treeherder.mozilla.org/jobs?repo=try&revision=501c7c48fa5435f07dc401f75f0859ca6b3d503e

Comment 1

[Mike Kaply [:mkaply]]

I was told by Aryx to NI you.

Comment 2

[Marco Castelluccio [:marco]]

That's confusing, aren't we falling back on something else when the bugbug optimization fails?

Comment 3

[Andrew Halberstadt [:ahal]]

Looks like only if we define a fallback for the strategy:
https://searchfox.org/mozilla-esr102/rev/1486e5e669f44ccdae59bd068e68b2dd7ffb870e/taskcluster/gecko_taskgraph/optimize/bugbug.py#147

And that push is using this strategy:
https://hg.mozilla.org/try/rev/41617ce08cbf1c2951f474db0528d97f3f7c7405#l1.7

IIRC we decided not to use the fallback on try because we didn't want to silently use the naive scheduling and have people complain when the tasks it gives are bogus. We figured it was better to be explicit that the scheduler isn't working.

Mike, I believe the issue here simply that the delta of files changed is so large (due to pushing to esr102 I suppose), that it takes the algorithm a really long time to process everything. Unfortunately I'm not sure using mach try auto with ESR branches has ever worked tbh, but could be mistaken.

Comment 4

[Marco Castelluccio [:marco]]

(In reply to Andrew Halberstadt [:ahal] from comment #3)

IIRC we decided not to use the fallback on try because we didn't want to silently use the naive scheduling and have people complain when the tasks it gives are bogus. We figured it was better to be explicit that the scheduler isn't working.

Good memory!