This ensures we don't run every build with every push via ./mach try auto. It
introduces a new 'optimization-overrides' try_config that can be used to
replace optimizations. For now, there is no user interface to pass this in via
the 'mach try' command line.
Differential Revision: https://phabricator.services.mozilla.com/D68207
Changes:
Applies the `filter_tasks_by_blacklist` method to try syntax pushes as well.
- moved `TARGET_TASK_BLACKLIST`and `filter_tasks_by_blacklist` method to live in `taskcluster/taskgraph/target_tasks.py`.
- removed existing filters against `ccov, windows10-aarch64` and `android-hw` filters against try syntax pushes.
- update imports for `fuzzy` and `chooser` selectors to refer to the new location of `filter_tasks_by_blacklist` method.
The reason for moving the logic (again) from `tools/tryselect` to `taskcluster/` is due to the placement of `try_option_syntax` and `target_tasks` files and both of those files handle the processing of `mach try syntax` pushes.
Differential Revision: https://phabricator.services.mozilla.com/D71698
Changes:
- implement filtering of taskgraph items against a list of known task filters in `tasks.py`.
- apply these filters to both `fuzzy` and `chooser` selectors, unless `--full` is specified.
Differential Revision: https://phabricator.services.mozilla.com/D70097
--HG--
extra : moz-landing-system : lando
Changes:
- implement filtering of taskgraph items against a list of known task filters in `tasks.py`.
- apply these filters to both `fuzzy` and `chooser` selectors, unless `--full` is specified.
Differential Revision: https://phabricator.services.mozilla.com/D70097
--HG--
extra : moz-landing-system : lando
This prevents a race condition where the watchman hook can potentially
invalidate the cache in-between the call to 'isfile' and 'getmtime'.
Depends on D69189
Differential Revision: https://phabricator.services.mozilla.com/D69190
--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 ensures we fail with invalid module paths early. Otherwise users wouldn't
find out until the decision task fails.
Differential Revision: https://phabricator.services.mozilla.com/D68464
--HG--
extra : moz-landing-system : lando
These routes are applied to all tasks except the decision task. There
is currently no validity checking in the frontend, so if the provided
routes aren't valid the decision task will fail.
Differential Revision: https://phabricator.services.mozilla.com/D67828
--HG--
extra : moz-landing-system : lando
This adds an optional routes key to the task_task_config schema,
which is a list of strings. Anything in this key is added to the list
of routes for tasks scheduled by the decision task.
Differential Revision: https://phabricator.services.mozilla.com/D67827
--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 ensures we fail with invalid module paths early. Otherwise users wouldn't
find out until the decision task fails.
Differential Revision: https://phabricator.services.mozilla.com/D68464
--HG--
extra : moz-landing-system : lando
I'm unsure of the root cause as the file should exist if generate_tasks has worked, but this should avoid errors in the meantime while we investigate.
Differential Revision: https://phabricator.services.mozilla.com/D67833
--HG--
extra : moz-landing-system : lando
Neither of these selectors involve the user choosing tasks, so showing
estimates or saving them in the 'mach try again' history doesn't make much
sense.
Differential Revision: https://phabricator.services.mozilla.com/D66628
--HG--
extra : moz-landing-system : lando
This allows us to change the default optimization strategy used in try pushes.
While probably not super useful to developers, it can help us easily test
changes to new and experimental optimizations on try.
This also changes the default to the 'bugbug_push_schedules' strategy, since
SETA is more or less random and shouldn't be used by 'mach try auto'. In the
future, we'll switch this back to simply using the default optimization as the
default will ideally be the best one that we have.
Differential Revision: https://phabricator.services.mozilla.com/D65746
--HG--
extra : moz-landing-system : lando
The 'auto' in 'mach try auto' stands for two things:
1. It automatically picks tasks for you.
2. It runs the same scheduling algorithms as autoland.
It accomplishes this by creating a new target_tasks method that spoofs the
'project' parameter to autoland.
Differential Revision: https://phabricator.services.mozilla.com/D60184
--HG--
extra : moz-landing-system : lando
Add filename support for plain display
Update fzf version in tests
Update tooltool url for fzf
Differential Revision: https://phabricator.services.mozilla.com/D66571
--HG--
extra : moz-landing-system : lando
Remove use of requests module in preview pane
Reformat task duration data to avoid reprocessing in preview pane
Avoid loading task durations json more than once.
Increase required fzf version, use temporary file instead of arglist
Differential Revision: https://phabricator.services.mozilla.com/D65094
--HG--
extra : moz-landing-system : lando
Changes:
Remove `ubuntu-bionic` flag that was used during development to enable use of ubuntu1804-test docker image.
Remove unnecessary conditional and in the process rewrite how `runtests.py` checks the environment for `pactl` prior to running mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D65389
--HG--
extra : moz-landing-system : lando
In |mach try fuzzy| there's a TARGET_TASK_FILTERS variable that we use to make
it more difficult to run certain kinds of expensive / resource constrained
tasks. The problem is that the only way to run these is to use '--full' at
which point there's no way to distinguish which tasks are "valid" (i.e run on
mozilla-central) and which tasks don't.
This adds a flag that will ensure the default set truly matches what we run
on central.
Differential Revision: https://phabricator.services.mozilla.com/D64648
--HG--
extra : moz-landing-system : lando