This patch affects the following linux64-qr test jobs (for both opt and debug):
- Stops running reftest-no-accel on central, since they don't seem to provide
much value over regular reftests.
- Starts running mochitest-gpu on central.
- Starts running crashtests, reftests, jsreftests, mochitest-gpu and
mochitest-webgl on mozilla-inbound and autoland (this matches the set of
tests on central).
- Promotes all the tests running on central/autoland/inbound to tier-1.
MozReview-Commit-ID: LgU4VgGz7S
This will fail until Bug 1265537 lands, which is what will switch windows to SIMPLE NAME package format.
MozReview-Commit-ID: J0zVLptvxNO
--HG--
extra : rebase_source : 6c388f24bce78ee6f6a8d7eb17cd6bce036b1d35
Because of bug 1338651, we need to stick to BBB macosx64 builds for now.
MozReview-Commit-ID: AwQc5r6ikUN
--HG--
extra : rebase_source : d5ee1605bf5ec70223e7676bd2d2fd760841d59a
The "generate-build-stats" mozharness action collects a bunch of build
system metrics, including build_resources.json, ctors count, and
installer size and reports them by writing special messages that
log parsers read.
Before this commit, this mozharness action occurred sometime after
"build." But relative ordering to other actions was not consistent
and appears to be significantly cargo culted.
4e61e69a383c (bug 1304508) changed the "check" mozharness action to
invoke `mach build check` instead of `make` directly. An unintended
consequence of this is that `mach build` replaced the
build_resources.json file from the build itself with one measuring
`make check`. This made the "build time summary" metric take a nose
dive.
This commit works around the issue introduced by 4e61e69a383c by
reordering the mozharness actions so "generate-build-stats" follows
immediately after the "build" action. Not only does it now occur
before the "check" action, but it also occurs before uploading and
other actions.
I'm not sure why "generate-build-stats" is its own action and not
part of "build" itself. As the diff shows, numerous instances of
"generate-build-stats" are commented out, which means we aren't
collecting metrics. "generate-build-stats" is also missing from a
handful of mozharness configs, including Windows Clang builds. I'm
not sure what the history is (it is likely varied and almost certainly
involves a fair amount of cargo culting), but I think it is a bug that
we aren't collecting build metrics for every build. I would like to
fix this. And moving "generate-build-stats" immediately after "build"
should make that transition easier.
MozReview-Commit-ID: 7jNTVWRvMnh
--HG--
extra : rebase_source : 0b5fd1f462caa5c283ba7e1b693fdc5b8b948add
This is pretty straight-forward.
Sadly, this will require local developers to add a "skin" product
flavor to their invocations, like:
./mach gradle app:assembleLocalAustralisDebug
In addition, this shows how many different variants of the Gradle
product flavor are embedded into our automation configurations. I
can't solve that at this time.
Since I was here, I took the time to rename "automation" to
"official", which makes "localAustralis" the default in Android
Studio, avoiding a common issue with new builders producing an APK
that doesn't include omni.ja in the IDE.
MozReview-Commit-ID: CtU7zFpNCob
This is pretty straight-forward.
Sadly, this will require local developers to add a "skin" product
flavor to their invocations, like:
./mach gradle app:assembleLocalAustralisDebug
In addition, this shows how many different variants of the Gradle
product flavor are embedded into our automation configurations. I
can't solve that at this time.
Since I was here, I took the time to rename "automation" to
"official", which makes "localAustralis" the default in Android
Studio, avoiding a common issue with new builders producing an APK
that doesn't include omni.ja in the IDE.
MozReview-Commit-ID: CtU7zFpNCob
--HG--
extra : rebase_source : 477ef683f850ff11cfa128e17855666bb7758a7a
This test-only "run-on-projects" option indicates that the test should run on
exactly the projects where its parent build runs. This avoids the situation
where a build is configured to *not* run on a project, but some wayward test
didn't get the memo and "pulls in" the build anyway. This has been
particularly problematic with win64-asan/opt.
MozReview-Commit-ID: 8UP6FsXBohy
--HG--
extra : rebase_source : 237ea2898767da8e4561d1f6884e5add92a7bde2
Geoff Brown
Kartikaya Gupta
Kim Moir
Carsten "Tomcat" Book
Simon Fraser
Wes Kocher
Wander Lairson Costa
Ben Hearsum
Mike Hommey
Justin Wood
Iris Hsiao
Rob Thijssen
Gregory Szorc
Nick Alexander
Sebastian Hengst
Dustin J. Mitchell
Ryan VanderMeulen
Shriram Kunchanapalli
Rob Wood