Changes:
- disable wholesale the `media-source` subsuite within web-platform-test
Attempts were made to isolate the tests that cause the test harness to lock up with a permission issue on `Ahem.ttf` however the attempts were unsuccessful in isolating the tests to a manageable set. It appears the solution is to simply stop running `media-source` tests on windows10-aarch64 as that seems to have solved the problem in a previous try run.
Differential Revision: https://phabricator.services.mozilla.com/D28778
--HG--
extra : moz-landing-system : lando
This uniformizes the artifact name across platforms. We may want to do
the same for other toolchains, but it bears the question whether xz is
reliably available on users' Windows machines, while it doesn't matter
for rust, since mach bootstrap pulls it with rustup rather than from
automation, contrary to other toolchains.
Differential Revision: https://phabricator.services.mozilla.com/D28780
--HG--
extra : moz-landing-system : lando
Currently, all things running via run-task don't really care that the
current directory is set to /. However, on generic-worker, many things
assume the current directory is the task directory, which varies by
task, and wrapping them with run-task fails because it resets the
current directory.
Differential Revision: https://phabricator.services.mozilla.com/D28018
--HG--
extra : moz-landing-system : lando
Analogously to the existing `linux64-clang-8-android-cross` build, this
build is a linux x86-64 build with runtime library support for aarch64.
Depends on D28405
Differential Revision: https://phabricator.services.mozilla.com/D28406
--HG--
extra : moz-landing-system : lando
We need this image for building clang on machines with arm64
sysroots. (Note that this image *is* a linux x86-64 image, just with
some arm64 cross-compilation packages available.)
Differential Revision: https://phabricator.services.mozilla.com/D28404
--HG--
extra : moz-landing-system : lando
This is not strictly required in mozilla-central, as `mach` sets
the encoding of the output to UTF-8.
Differential Revision: https://phabricator.services.mozilla.com/D28861
--HG--
extra : moz-landing-system : lando
If we use the downloaded manifest then any bug that leads to an error in the manifest
may be propogated forward. Instead force the manifest to be built from scratch in CI.
Differential Revision: https://phabricator.services.mozilla.com/D28809
- stop mochitest-headless on windows10
- stop mochitest-headless on linux64/debug
- make mochitest-headless tier-2
- make mochitest-headless run on m-c/try
Differential Revision: https://phabricator.services.mozilla.com/D28715
--HG--
extra : moz-landing-system : lando
It was necessary when it was a different version than win64-rust, but
that's not the case anymore.
Differential Revision: https://phabricator.services.mozilla.com/D28761
--HG--
extra : moz-landing-system : lando
These artifacts are "internal" because we can't redistribute them, but
downloading them into an interactive task is not redistribution.
Differential Revision: https://phabricator.services.mozilla.com/D28656
--HG--
extra : moz-landing-system : lando
This patch leaves wpt running against fennec on androidx86 as tier2, adds wpt to run against geckoview testactivity on android x86_64 as tier3, and adds enough metadata to run_info_extras to help differentiate the two in expectation files. Fennec is "os == android and not e10s", while geckoview is "os == android and e10s".
Differential Revision: https://phabricator.services.mozilla.com/D27182
--HG--
extra : moz-landing-system : lando
Bug 1474897 changed things such that Windows builds ended up in the
linux/macosx branch. That still works somehow, but ends up breaking when
wrapping with run-task. This change restores the originally intended
command line.
Differential Revision: https://phabricator.services.mozilla.com/D28017
--HG--
extra : moz-landing-system : lando
On windows, the generated path will be close to the path length limits, which
causes `mach try` to fail.
Differential Revision: https://phabricator.services.mozilla.com/D28554
--HG--
extra : moz-landing-system : lando
This patch leaves wpt running against fennec on androidx86 as tier2, adds wpt to run against geckoview testactivity on android x86_64 as tier3, and adds enough metadata to run_info_extras to help differentiate the two in expectation files. Fennec is "os == android and not e10s", while geckoview is "os == android and e10s".
Differential Revision: https://phabricator.services.mozilla.com/D27182
--HG--
extra : moz-landing-system : lando
This officially makes 'moztest.resolve' the source of truth when it comes to
suite names. It aligns that file with the names used in both the
desktop_unittest and android_emulator_unittest scripts.
Differential Revision: https://phabricator.services.mozilla.com/D27555
--HG--
extra : moz-landing-system : lando
Currently we have the concept of a "suite" and a "flavour" in our task
configuration. Typically, the "suite" refers to the high-level test harness
like "mochitest" or "reftest", whereas the flavour is more specific, e.g
"browser-chrome-instrumentation" or "crashtest". However the line between suite
and flavour is not applied with any semblance of consistency which results in
inconsistent naming throughout the tree.
This patch gets rid of the concept of "flavours" entirely (at least when it
comes to task configuration). A suite is a type of test run, for example:
- mochitest-plain
- mochitest-devtools-chrome
- mochitest-browser-chrome-instrumentation
- jsreftest
- reftest
- firefox-ui-functional-remote
etc
There is no confusion here between suites and flavours because flavours don't
exist. However, there are a couple of places where we *do* need to know what
"test harness" is used to run a suite. These cases are:
1. For SCHEDULES moz.build rules
2. For the desktop_unittest.py mozharness script which takes arguments like
--mochitest-suite=browser (this is not a compelling use of this information
and should be refactored to work more like the android_emulator_unittest.py
script)
So to get this information, this patch introduces a new concept of a "category"
which is the overall "test harness" that runs the suite. For many suites, the
"category" is identical to the suite name. Unlike flavours, "categories" have
no bearing on how we call or refer to the suite.
Differential Revision: https://phabricator.services.mozilla.com/D27554
--HG--
extra : moz-landing-system : lando
Turns out these suites were hardcoded to be non-e10s in the mochitest harness.
So while it looked like they were working with e10s in treeherder, they were
actually still running with it disabled.
Turning e10s on causes both suites to permafail due to timeouts.
Depends on D28386
Differential Revision: https://phabricator.services.mozilla.com/D28387
--HG--
extra : moz-landing-system : lando
This was regressed by bug 1544816 but the test never ran on the push that regressed.
This patch also updates the 'files-changed' for the tryselect task.
Differential Revision: https://phabricator.services.mozilla.com/D28386
--HG--
extra : moz-landing-system : lando
This patch leaves wpt running against fennec on androidx86 as tier2, adds wpt to run against geckoview testactivity on android x86_64 as tier3, and adds enough metadata to run_info_extras to help differentiate the two in expectation files. Fennec is "os == android and not e10s", while geckoview is "os == android and e10s".
Differential Revision: https://phabricator.services.mozilla.com/D27182
--HG--
extra : moz-landing-system : lando