Implement a smarter platform filter for the bugbug scheduling algorithm
Categories
(Firefox Build System :: Task Configuration, enhancement)
Tracking
(firefox77 fixed)
Tracking | Status | |
---|---|---|
firefox77 | --- | fixed |
People
(Reporter: ahal, Assigned: ahal)
References
(Blocks 1 open bug)
Details
Attachments
(6 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
In bug 1624902 I implemented a filter that reduces bugbug's chosen platforms to debug only. However we can do something smarter. My current idea is something like this (though may morph over time):
-
Break each manifest into tiers based on their confidence intervals, e.g:
a. Tier 1: >0.9
b. Tier 2: >0.75
c. Tier 3: >0.5
d. Tier 4: >0 -
Assign constraints to each tier, e.g:
a. A manifest in tier 1 is guaranteed to run in at least one task from every major configuration.
b. A manifest in tier 2 is guaranteed to run in at least one task from every OS family.
c. A manifest in tier 3 is guaranteed to run in at least one mobile and one desktop platform.
d. A manifest in tier 4 is guaranteed to run in at least one task -
Overall, try to cover as many different configurations as possible while satisfying the above constraints. This way we try to spread out our coverage across as many configurations as possible while minimizing duplication.
This is just an example, we may end up with more or fewer tiers, different constraints, different thresholds etc.
Assignee | ||
Comment 1•5 years ago
|
||
This change is beneficial for two reasons:
- Improvement on the single responsibility principle
- Platform filter isn't 'bugbug' specific. E.g, the 'relevant tests' optimizer
could also theoretically use this. Having it as a standalone optimizer allows
us to compose it with other strategies.
Assignee | ||
Comment 2•5 years ago
|
||
Assignee | ||
Comment 3•5 years ago
|
||
Hm, implementing the above as stated won't be possible. We won't be able to make those guarantees as the optimizers process tasks one at a time, so have no idea what is coming. I'm implementing something a lot simpler for now, and we can iterate on it over time.
Assignee | ||
Updated•5 years ago
|
Comment 5•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Assignee | ||
Comment 7•5 years ago
|
||
Depends on D71314
Assignee | ||
Comment 8•5 years ago
|
||
Depends on D72464
Assignee | ||
Comment 9•5 years ago
|
||
Depends on D72465
Comment 10•5 years ago
|
||
bugherder |
Assignee | ||
Comment 11•5 years ago
|
||
Updated•5 years ago
|
Comment 12•5 years ago
|
||
Comment 13•5 years ago
|
||
bugherder |
Assignee | ||
Updated•5 years ago
|
Comment 14•5 years ago
|
||
Comment 15•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0414f57713e8
https://hg.mozilla.org/mozilla-central/rev/c5df25796d9b
https://hg.mozilla.org/mozilla-central/rev/a34695d9b99d
Description
•