This patch makes it possible to collect code coverage for xpcshell tests using the linux64-jsdcov build. It also enables the use of a 'coverage' flag to disable tests when they are instrumented with the js debugger for code coverage. Lastly, it uses the 'coverage' flag to disable certain tests.
MozReview-Commit-ID: 97VFkJmlwQn
--HG--
extra : rebase_source : 26c841f5a68f927889c0903e701bfde4b7ca84ac
I want to get Servo vendored into servo/. The previous plan was to
replace the dummy geckolib with the real deal when the vendoring is
done. Unfortunately, this will require a significant `cargo vendor`
change, which we want to punt on for a bit.
So, this commit moves our dummy geckolib outside of servo/ so we
don't need to `cargo update` or `cargo vendor` when the real servo/
is installed.
The change to toolkit/library/rust/shared/Cargo.toml can be reverted
in the stylo repo to allow it to use the real geckolib.
We also update the taskgraph code for detecting Servo. Previously,
it looked for a file in the possibly-vendored servo/ directory. Once
the vendoring happens, this check will always pass. But without the
real geckolib, the Servo builds will fail. So, we change the check
to look for the real geckolib. This is implemented a bit hackily.
But it will be short-lived until we run `cargo vendor`.
MozReview-Commit-ID: CxGTwy6bK9j
--HG--
rename : servo/ports/geckolib/Cargo.toml => toolkit/library/geckolib/Cargo.toml
rename : servo/ports/geckolib/lib.rs => toolkit/library/geckolib/lib.rs
extra : rebase_source : c0e9c867ae74c4eb124e72dc481fd8dc814e65e7
-w, --taskcluster-worker: schedule taskcluster-worker jobs.
This is necessary to relieve the load of the small pool of data center
machines.
MozReview-Commit-ID: IiOLHUs2ALi
--HG--
extra : rebase_source : 96acbbd40aef856f68c7ab94ae23bcee4f2f078d
This test suite involves a bunch of python tests which don't require
configure or any generated binaries to run. We can split them out into a
Taskcluster linter type task to run directly on the source tree in
parallel with builds.
MozReview-Commit-ID: 9ux3rAuFXAY
--HG--
extra : rebase_source : 95378cd686644e34ea017c682d7384906b17d13a
This patch has a few parts to make this work:
1) more tests pass on ubuntu 16, so remove old fail-if conditions
2) no support for GL_ARB_gpu_shader5, we cherry pick from updated ANGLE code
3) disable test_capture.html as it leaks on ASAN
MozReview-Commit-ID: BSSiTFvF9jN
Previously the run-wizard script would add a command to source the virtualenv in ~/.bashrc after
mozharness finished setting things up. This is fragile, assumes people are using bash, etc. Plus
it appeared to intermittently fail for some users.
Instead, this activates the virtualenv directly from individual mach commands that need it. This
guarantees we will always be using the virtualenv if required (and won't be using it if not). The
'activate_this.py' script is invoked the same way that we do it for in-tree mach commands:
https://dxr.mozilla.org/mozilla-central/rev/9c06e744b1befb3a2e2fdac7414ce18220774a1d/python/mozbuild/mozbuild/virtualenv.py#456
MozReview-Commit-ID: CfcoiVJXQTl
--HG--
extra : rebase_source : da01d1ce1bd9b41c89922e989f857c4de8c09341
Rename the base external media tests from "external-media-tests" to
"external-media-tests-base", to disambiguate them from the other tests in the
suite, as well as the set of all external media tests.
Adjust tests that are run per platform so that all external media tests are run
on linux and windows. Adjust the platform tests so that they select the
external-media-tests set, rather than adding individual external media tests to
each platform set.
MozReview-Commit-ID: DRiQQA1BB9n
--HG--
extra : rebase_source : 88b46930bc1fe09062ebcb445e75d1131a2f0116
Considering docker images contents depend very much on the moment they
were built, it is possible that two images with the same hash in the
taskcluster index (at different levels) have different contents. When
this happens, the build or test results could be significantly
different between e.g. try and mozilla-central, possibly leading to
misleading results at landing time.
So if for some reason multiple levels have images for the same hash, the
one used at the highest level should be prefered, such that try uses the
same as mozilla-central once mozilla-central generates the image for
that hash, even if there is an image previously generated for try.
--HG--
extra : rebase_source : 57f593a530da02f9f576872404915c26af544688
Considering docker images contents depend very much on the moment they
were built, it is possible that two images with the same hash in the
taskcluster index (at different levels) have different contents. When
this happens, the build or test results could be significantly
different between e.g. try and mozilla-central, possibly leading to
misleading results at landing time.
So if for some reason multiple levels have images for the same hash, the
one used at the highest level should be prefered, such that try uses the
same as mozilla-central once mozilla-central generates the image for
that hash, even if there is an image previously generated for try.
--HG--
extra : rebase_source : 3f92c1c97a8805cd2d4d6de791863936ed69e8d0
For correct platform name in TH, the buildername must contain the pgo
string in the buildername. We work a bit more generic by matching any
build variant.
Bump the Android builders to the latest beta release to reduce
the variance when we update Firefox 53 to 1.15.0 stable early
in the Aurora phase.
Android builds were moved to 1.15 early to address a code generation
issue with devices without neon.
Work around an issue with tarball naming in the cargo packages.
MozReview-Commit-ID: KQfkWmXV9hQ
--HG--
extra : rebase_source : 9448e0b948740fc3905ef70c8df316dc7342d52e
