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
We are starting to spin off more and more "variants" of test suites. These are
usually just duplicates of our pre-existing tasks, except with an additional
pref set.
Currently there are two variants (serviceworker-e10s and socketprocess-e10s),
but a third will be added soon (fission). This change ensures we handle these
types of requests in a consistent and well defined manner. It also splits tasks
in a loop, so we don't accidentally risk combinatorial explosion.
Variants should typically be reserved for very large changes that will impact
the entire codebase (think e10s).
Differential Revision: https://phabricator.services.mozilla.com/D28061
--HG--
extra : moz-landing-system : lando
We only want to append the action TASK_ID to the task dependencies when the taskGroupId doesn't match, otherwise we hit dup dependency errors.
Differential Revision: https://phabricator.services.mozilla.com/D27994
--HG--
extra : moz-landing-system : lando
Changes:
- most tests are skipped using `moz.build` configuration file.
- `MultiWriterQueue` had to be skipped with `define` clauses in the test file due to build bustages when its `moz.build` file was used.
Differential Revision: https://phabricator.services.mozilla.com/D27944
--HG--
extra : moz-landing-system : lando
this change adds support for parallel gcp builds for the following android build configurations:
- android-api-16
- opt
- debug
- android-x86
- opt
- android-x86_64
- opt
- debug
- android-aarch64
- opt
- debug
implementation notes:
- this patch mostly mirrors the equivalent windows-on-gcp patch at: https://phabricator.services.mozilla.com/D24865
- gcp builds are triggered with a treeherder tier 3 flag so that they are only displayed in the treeherder ui when the user has a tier 3 flag set.
- gcp builds use a th build symbol of "Bg" to make them easy to differentiate from ec2 builds in the treeherder ui.
- gcp builds use a perfherder "gcp" flag to make them easier to differentiate from ec2 builds in the perfherder ui.
Differential Revision: https://phabricator.services.mozilla.com/D26584
--HG--
extra : moz-landing-system : lando
