Currently test manifests are loaded by instantiating a TestResolver and
traversing moz.build files to find manifests.
With 'manifest-scheduling', we'll want to grab the manifests directly from the
bugbug service instead. Initially we'll want to enable manifest-scheduling with
|mach try auto|, but not on autoland yet.
This patch will allow |mach try auto| to set the parameter that causes bugbug
to be used (see future commits in this bug).
Differential Revision: https://phabricator.services.mozilla.com/D76522
Instead of a boolean, it's now a set of projects for which tasks should be removed.
If they project doesn't match the specified set it will be kept.
This ensures tasks that have these optimzers applied won't run on |mach try auto|.
Differential Revision: https://phabricator.services.mozilla.com/D76987
This feature A) scheduled way too many tasks, and B) won't be that useful anyway once we
switch to manifest-scheduling.
Differential Revision: https://phabricator.services.mozilla.com/D75399
When handling bug 1632429, I found some tests that worked on Python 2, but not Python 3.
They were marked accordingly as "expected failures". However, my system version of Python
is 3.8, while CI (and a non-trivial number of devs, probably) use 3.6.
Some of these tests marked as xfail were actually still working on versions of Python until 3.8.
The failure of this test was due to a change in default tarfile format. Explicitly setting this
format makes the tests pass in all relevant python versions.
Differential Revision: https://phabricator.services.mozilla.com/D74337
As |./mach| commands are migrated to python3, "taskgraph" needs to be compatible while still working with python2.
This patch migrates several iter*() calls and python2-specific imports to work with "six" instead.
Note that there's still python2-specific parts of taskgraph, I'm just modifying the pieces that are affecting
the code paths that I'm currently migrating (in this case, |./mach try|
Differential Revision: https://phabricator.services.mozilla.com/D73397
With dynamic-test-selection, we'll also need to query the bugbug service from
the transforms. Let's move the querying logic to a utility file to share it
more easily.
Differential Revision: https://phabricator.services.mozilla.com/D73088
This adds a parameter that will cause a task to sum all the confidence
thresholds of the relative manifests it contains to gather a larger overall
task confidence.
This also adds a new strategy + shadow-scheduler to go along with it.
Differential Revision: https://phabricator.services.mozilla.com/D71314
This change is beneficial for two reasons:
1) Improvement on the single responsibility principle
2) 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.
Differential Revision: https://phabricator.services.mozilla.com/D71210
We'll want some kind of backstop no matter what optimization algorithm we use.
We don't want to go too long without running any given task so we can find
regressions quickly and have a good merge candidate.
This pulls the logic that handles this out of the SETA strategy and into its
own strategy.
This will also make the SETA shadow scheduler more representative of what the
algorithm is doing.
Note in the future we may find ways to make this backstop more efficient (i.e
only run tasks that didn't run in the last 9 pushes for example).
Depends on D68621
Differential Revision: https://phabricator.services.mozilla.com/D68622
--HG--
extra : moz-landing-system : lando
I'd like to implement a 'backstop' strategy, such that it will prevent all other
optimizers from removing tasks under certain conditions (e.g every 10th push).
The nicest way to implement this seems to be an 'All' composite strategy
(similar to 'Either' which this patch renames to 'Any'). This means we could
do something like:
All("seta", "backstop")
which means we would only remove tasks if *all* substrategies say to remove
tasks.
Differential Revision: https://phabricator.services.mozilla.com/D68620
--HG--
extra : moz-landing-system : lando
We'll want some kind of backstop no matter what optimization algorithm we use.
We don't want to go too long without running any given task so we can find
regressions quickly and have a good merge candidate.
This pulls the logic that handles this out of the SETA strategy and into its
own strategy.
This will also make the SETA shadow scheduler more representative of what the
algorithm is doing.
Note in the future we may find ways to make this backstop more efficient (i.e
only run tasks that didn't run in the last 9 pushes for example).
Depends on D68621
Differential Revision: https://phabricator.services.mozilla.com/D68622
--HG--
extra : moz-landing-system : lando
I'd like to implement a 'backstop' strategy, such that it will prevent all other
optimizers from removing tasks under certain conditions (e.g every 10th push).
The nicest way to implement this seems to be an 'All' composite strategy
(similar to 'Either' which this patch renames to 'Any'). This means we could
do something like:
All("seta", "backstop")
which means we would only remove tasks if *all* substrategies say to remove
tasks.
Differential Revision: https://phabricator.services.mozilla.com/D68620
--HG--
extra : moz-landing-system : lando
The bugbug scheduler currently chooses which manifests are important, and we
then run *every* task that contains those manifests. This is likely overkill
and we can reduce the number of configurations we run these manifests on.
Differential Revision: https://phabricator.services.mozilla.com/D68466
--HG--
extra : moz-landing-system : lando
The bugbug scheduler currently chooses which manifests are important, and we
then run *every* task that contains those manifests. This is likely overkill
and we can reduce the number of configurations we run these manifests on.
Differential Revision: https://phabricator.services.mozilla.com/D68466
--HG--
extra : moz-landing-system : lando
This converts `--setenv` into `env` in `try_task_config` at parameter
generation time.
Differential Revision: https://phabricator.services.mozilla.com/D66537
--HG--
extra : moz-landing-system : lando
There are a number of settings that have equivalent expressions in
`try_options` (used for try syntax) and `try_task_config` (used for other try
selectors). Rather than requiring task generation code to understand both
formats, this converts the try syntax specification to `try_task_config` at
parameter generation time.
Differential Revision: https://phabricator.services.mozilla.com/D66536
--HG--
extra : moz-landing-system : lando
Update existing unit test aliases for linux64 to include the new 18.04 platforms.
Differential Revision: https://phabricator.services.mozilla.com/D62137
--HG--
extra : moz-landing-system : lando
For mozilla-central, all the code related to taskgraph lives in
taskcluster/taskgraph. Thunderbird's build requirements are evolving, and
we want to be able to have repository-specific code. The natural place for it
to live is an a package beside taskcluster/ci. Add that to python path,
and provide some hooks for adding to the various registries in taskgraph.
Differential Revision: https://phabricator.services.mozilla.com/D60540
--HG--
extra : moz-landing-system : lando
