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
When trying to remove an ubiquitous group like tc(), it's hard to tell where the
error was located without grepping my filesystem. This makes it a bit easier to
find and fix these errors.
MozReview-Commit-ID: 8NjvB5zOoqb
..and remove support for when.files-changed in the test kind. It is still used
for other kinds, and that will be addressed in other bugs.
This is re-landing of this bug, now without running test-verify excessively.
MozReview-Commit-ID: GBilXAktICZ
For example, jittests will be an inclusive test suite; all files which might
affect the suite are tagged with
SCHEDULES.inclusive += ['jittest']
but those files usually also schedule all of the exclusive components (including
the platform families android, linux, macosx, and windows). This makes sense:
those files could potentially affect any other test suite on any platform too.
But the jittest job on Android, for example, needs to run only if the jittest
component is scheduled -- it does not need to just because something
Android-related changed. So its optimization should be {skip-unless-schedules:
['jittest']}, not {skip-unless-schedules: ['jittest', 'android']}.
This fix "figures out" the distinction by looking at what kind of component the
test suite is. Maybe that is too magic, and we should also have to write
"component: implicit" in the tests/*.yml file.
MozReview-Commit-ID: EIsVvi1vziE
This also renames the existing test sets for qr to be linux-specific, so
we can have a different test set for windows QR builds. The windows10-64-qr
gpu mochitests will run on all nightly branches (so inbound, autoland, m-c,
try) by default.
MozReview-Commit-ID: F2NjCTHYg13
Previously we had linux64-qr as the only QuantumRender test platform.
Soon we will have windows10-64-qr as well and (eventually) we will have
some macOS -qr tests as well. So this patch generifies the existing
regexes to match these platforms.
In a couple of places redundant platform matching lines were removed, to
avoid the case where a given platform (e.g. windows10-64-qr) matches
multiple regexes (e.g. .*-qr/.* and windows.*) which produces an error.
MozReview-Commit-ID: 8YO9lQETVYM
With migration of talos machines from buildbot to Taskcluster, we need a
way to run jobs in Taskcluster without affecting production.
We accomplish this task by using the same approach we use for Linux:
when we give the --taskcluster-worker flag, decision task switches from
buildbot-bridge to Taskcluster Windows work-type.
MozReview-Commit-ID: LU5oaGCZ8uz
Building with "Linux x64 JSDCov", each suite of tests will produce a list of JSDCov artifacts (.json). This patch compresses all JSDCov artifacts into 1 zip file for each suite upon tests completion.
MozReview-Commit-ID: DaNLOQuW2lc
When first introduced, test-verify was only run when .js/.html/.xul/.xhtml files
were changed. Recently, it seems to run on every push. This is a speculative fix:
There may be confusion between "test-verify" and "test-verification" so I am
using "test-verify" consistently.
Many of the 'test' tasks key the entire 'mozharness' section by-test-platform.
This is bad because:
A) Configuration under 'mozharness' can't be shared across platforms
B) We can't use the 'job-defaults' simplification since merging is naive
Instead of keying the entire 'mozharness' section, this change keys only the
specific configuration that needs it.
MozReview-Commit-ID: EaPlOzsESQ3
Every task that uses the desktop_unittest.py or android_emulator_unittest.py
mozharness scripts needs to pass in either --<suite>-suite=<flavor>, or
--test-suite=<flavor> respectively.
In almost all cases, <suite> and <flavor> are identical to the value that is
already specified under the test['suite'] key. This means we can use a
transform to append these command line arguments and reduce the complexity of
the yaml files.
MozReview-Commit-ID: EaPlOzsESQ3
