Changes:
- added windows10-aarch64 to the filter for fuzzy, to require `--full` in order to trigger jobs
- return False for any test tasks that contain windows10-aarch64 to prevent users using old try syntax from overwhelming the limited number of hardware
Differential Revision: https://phabricator.services.mozilla.com/D27590
--HG--
extra : moz-landing-system : lando
With the shift to shippable builds we no longer run tests on osx/opt though many still push to try with old try syntax using -p macosx64 and get surprised by no tests. This patch fixes it as a bandaid by appending macosx64-shippable as a platform when macosx64 is specified, making the tests run in the appropriate cases. The expectation with the methodology of this patch is that we'll be killing try syntax support in the near future, eliminating the need for these sorts of bandaids
Differential Revision: https://phabricator.services.mozilla.com/D26048
--HG--
extra : moz-landing-system : lando
While try syntax is approaching its EOL, the fact that using it to do
artifact builds does some things subtly differently from using try
config is not helpful.
Depends on D22055
Differential Revision: https://phabricator.services.mozilla.com/D21312
--HG--
extra : moz-landing-system : lando
This patch removes linux64-jsdcov from the available builds on taskcluster along with any hacks used to run it. It also removes any 'coverage' entries that were added to skip tests.
Differential Revision: https://phabricator.services.mozilla.com/D7919
--HG--
extra : moz-landing-system : lando
This patch completely disables *ccov, and *jsdcov builds and tests when scheduling them through try option syntax as these build variations use a lot of resources and are rarely needed to be scheduled. The only way to schedule code coverage from now on will be with the |mach try fuzzy| tool.
Differential Revision: https://phabricator.services.mozilla.com/D3921
--HG--
extra : moz-landing-system : lando
You can still run them on a --disable-stylo build, as long as that works
(presumably not for long).
I think I haven't missed anything, but please double-check.
MozReview-Commit-ID: 3BIAEjgTLo5
With this in place, all `-j`obs will not run by default on try. This will omit
such jobs in most try pushes even if files-changed matches. This is
unfortunate, but better than running them unconditionally. Fuzzy selections,
and later `just try it` pushes, are the ultimate solution here.
With this change, a push with no try syntax or try_task_config.json will schedule
no tasks at all.
MozReview-Commit-ID: FGjqlDW1FT6
--HG--
extra : rebase_source : 727ceafb1b6d24f83c0c7382b6a877ecb65863ab
This sets the try_mode property, and parses the try message (if given), early
in the decision task and puts the results into the parameters.
The proximate need is to set optimze_target_tasks for some try modes and not
others. This also replaces the existing logic for parsing messages for certain
kinds, and makes the distinction between the different try modes a little
clearer.
MozReview-Commit-ID: AXJEGLh6pEV
--HG--
extra : rebase_source : 25e9966696d78d899783d9f38533d5ae66f9ccb9
extra : source : b53ff084c2d7968a1d9864d1343f2d9381fb652b
This sets the try_mode property, and parses the try message (if given), early
in the decision task and puts the results into the parameters.
The proximate need is to set optimze_target_tasks for some try modes and not
others. This also replaces the existing logic for parsing messages for certain
kinds, and makes the distinction between the different try modes a little
clearer.
MozReview-Commit-ID: AXJEGLh6pEV
--HG--
extra : rebase_source : 03a10610aa3337269fe76a1196bb9b1665e1ab20
extra : source : b53ff084c2d7968a1d9864d1343f2d9381fb652b
This sets the try_mode property, and parses the try message (if given), early
in the decision task and puts the results into the parameters.
The proximate need is to set optimze_target_tasks for some try modes and not
others. This also replaces the existing logic for parsing messages for certain
kinds, and makes the distinction between the different try modes a little
clearer.
MozReview-Commit-ID: AXJEGLh6pEV
--HG--
extra : rebase_source : fdd8c3cfb9abf759a3c43c5713e62e4772c5bd06
This fixes the issue where "-u web-platform-tests-wdspec" scheduled
nothing. Now it will schedule a e10s-enabled run of wdspec tests.
MozReview-Commit-ID: AdHZqtk1hLy
--HG--
extra : rebase_source : 8d5926277b37952616c4dffdb20133868913bab2
The upload now uses MOZ_SCM_LEVEL to determine which secret and bucket to
upload to, so it can potentially run at any level.
This also modifies task descriptions to allow {level} in scopes, and updates
try syntax to allow `-j doc-upload` even though run-on-tasks says it doesn't
run on try by default.
MozReview-Commit-ID: Dm27TGPa7IM
--HG--
extra : rebase_source : f1131abc8cd639251e085c8ebf776827a6b831ed
extra : amend_source : b2b0cb253c7f6e90fdd710c2c788877411bd9e1d
The first version of the patch didn't account for the fact that if we did -p all we still couldn't do -u foo[Windows 8]
specifically: -p all means self.platforms is None
https://hg.mozilla.org/mozilla-central/file/16ffc1d05422/taskcluster/taskgraph/try_option_syntax.py#l563
Then we check if the *test* has a run_on_projects that has either `all` or `try`, it doesn't so we abort.
In new code, we merely set a flag to say don't-run-me-by-default and use that in a few places.
MozReview-Commit-ID: 6rjNVZvpYGA
--HG--
extra : rebase_source : 4c791c9e566a5eddc2bb2e820bab0090f9db1237
Land date changes to support windows nightlies onto central
MozReview-Commit-ID: 8wlzBReWe5r
--HG--
extra : rebase_source : 72def80209aefb656b236d5858d8bb1ef5a68aab
It's a bit hacky to single out 'build' dependencies, but most tasks have a dependency on a docker
image, so we can't blanket skip all 'job' tasks with any dependencies at all. This is far from ideal
but is an improvement on the current behaviour of running build dependencies all the time, even if
the 'job' task gets optimized away.
There is likely a cleverer solution, but that can be follow-up work.
MozReview-Commit-ID: 6T68LT5VSrg
--HG--
extra : rebase_source : 1a7c43891c6e5da9a13c588c1daeba6121a47750
This copies the behavior of mozilla-taskcluster when it
submits try pushes. This will allow us to eventually stop
using mozilla-taskcluster.
MozReview-Commit-ID: J9zC92AE7HZ
--HG--
extra : rebase_source : 36575ef1fa5c43b6b6d5c0243c323af69e4ebd23
The logic here is a bit tricky to grok, but essentially there are two kinds of "job" tasks, those that
should always be considered (and possibly be optimized away later due to "skip-unless-changed"), and
those that should only be considered if their associated build-platform is also going to be scheduled.
If -j is specified, that should supercede both cases.
This patch uses the prescence of the 'build_platform' attribute to draw the distinction.
MozReview-Commit-ID: H9SjeYuZ8F0
--HG--
extra : rebase_source : 4c33061e882533df74159f3299278619a06d5945
We have a `unittest_try_name` for all unit test tasks, and similarly a
`talos_try_name`. The `-j` flag controls tasks known as "jobs" (although the
word has dozens of other meanings, too). Some of those set `job_try_name`, but
others do not and have special-case support in `try_option_syntax.py`. With
this change, all "jobs" set `job_try_name` and the special-case is removed.
MozReview-Commit-ID: 9hvW7wBIl2B
--HG--
extra : rebase_source : 120b5e9e7aa8f81fe49e72f4dadafdbd145ac357
In order to migrate from buildbot to taskcluster gradually, we read an
external json file to tells the percentage of jobs that must run in
Taskcluster.
MozReview-Commit-ID: JQhvsXKpcLz
--HG--
extra : rebase_source : 0c1a83b31831b788fb374adcb9fd181f97121239
