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
Previously, we were downloading tooltool.py from random servers.
Considering tooltool.py is used to secure the download of future
components, downloading tooltool.py from potentially 3rd party
services was a major lapse in our end-to-end security, as a
compromised tooltool.py wouldn't honor integrity checks.
This commit copies the already vendored copy of tooltool.py into
the mozharness directory. A copy needs to be in the mozharness
directory because then a copy of mozharness without access to
a source checkout will have access to it.
We modify the code in mozharness that fetches tooltool to use
the copy from mozharness (unless `mach artifact toolchain` is
available).
Since a copy of tooltool.py is always reliably available, we
can remove all config entries related to tooltool.py.
MozReview-Commit-ID: C7ls1xWrPMq
--HG--
rename : python/mozbuild/mozbuild/action/tooltool.py => testing/mozharness/external_tools/tooltool.py
extra : rebase_source : d7b48d837805f9312c97b6e21c6527cc5f5018dc
The MACHTYPE bash variable is an odd thing that returns e.g.
x86_64-redhat-linux-gnu on a CentOS system, but x86_64-pc-linux-gnu
on a Debian system, and possibly something different on other distros.
mach valgrind-test is the only place actually relying on MACHTYPE.
Others rely on information from python modules. Uniformize that, and use
the more generic 'pc' rather than 'redhat'.
--HG--
rename : build/valgrind/i386-redhat-linux-gnu.sup => build/valgrind/i386-pc-linux-gnu.sup
rename : build/valgrind/x86_64-redhat-linux-gnu.sup => build/valgrind/x86_64-pc-linux-gnu.sup
extra : rebase_source : ad94ce69e8094d2b9ddae97a3d261945886c0a61
The main bug this fixes is that on reftest, the objdir needs to be added to the
whitelist on Windows. However, this only happens when running on Linux for some
reason.
Changing the --work-path and --obj-path arguments to --sandbox-read-whitelist
was more of a drive-by cleanup than anything necessary.
MozReview-Commit-ID: Dq8ZLETMzeM
--HG--
extra : rebase_source : 3d2cdda125205e76f86235eb373074899fe0789a
Using /home/worker is the build directory has a 30% talos performance
loss, because test machines has a /home mount directory.
MozReview-Commit-ID: 554IPMRWgzK
--HG--
extra : rebase_source : 00827d3f6bd705419bc801eb05b543af1ddc274f
On Taskcluster machines, /tools/buildbot doesn't exist. It turns out, nothing
refers to exes['python'] anyway, so we can just remove that (the preference is
to use sys.executable instead).
The references to exes['buildbot'] were all for sendchanges from builds to
tests, and those too are all gone now.
Lines like
'virtualenv': ['/tools/buildbot/bin/python', '/tools/misc-python/virtualenv.py'],
Were committing two sins: first, using a python executable from a random
virtualenv; and second, using a virtualenv.py from another random directory (in
this case, it's a utility script for a PuppetAgain module). Such lines are
replaced with a reference to /tools/virtualenv/bin/virtualenv, which is
installed for the express purpose of providing a virtualenv binary on testers
(for builds, we use the vendored copy).
MozReview-Commit-ID: 4iHX3B3MLyK
--HG--
extra : rebase_source : e4b4902a19d688b148c136bd10c706fc127cbf2d
On Taskcluster machines, /tools/buildbot doesn't exist. It turns out, nothing
refers to exes['python'] anyway, so we can just remove that (the preference is
to use sys.executable instead).
The references to exes['buildbot'] were all for sendchanges from builds to
tests, and those too are all gone now.
Lines like
'virtualenv': ['/tools/buildbot/bin/python', '/tools/misc-python/virtualenv.py'],
Were committing two sins: first, using a python executable from a random
virtualenv; and second, using a virtualenv.py from another random directory (in
this case, it's a utility script for a PuppetAgain module). Such lines are
replaced with a reference to /tools/virtualenv/bin/virtualenv, which is
installed for the express purpose of providing a virtualenv binary on testers
(for builds, we use the vendored copy).
MozReview-Commit-ID: 4iHX3B3MLyK
--HG--
extra : rebase_source : e4b4902a19d688b148c136bd10c706fc127cbf2d
Enable Stylo tests for win32, win64, and macosx64. Talos will be considered
separately.
MozReview-Commit-ID: BvTkddDX2Kk
--HG--
extra : rebase_source : 8d4df4469d4017b12bfbd33a98cc9f38111aa210
Using /home/worker is the build directory has a 30% talos performance
loss, because test machines has a /home mount directory.
MozReview-Commit-ID: zehcGJrUQX
--HG--
extra : source : feedcde68c2a54da210f03eb287ab5c862fc982b
extra : intermediate-source : 485d1af7805ad9fa0e701c3571fc1291fbfc6850
Our linux32-debug build is very slow to startup when running mochitests on aws.
Sometimes we see similar behavior on other linux platforms. Intermittently,
in this environment, startup takes longer than the 120 seconds that marionette
waits, resulting in test failures in bug 1261598. Increasing the marionette
startup timeout to 180 seconds appears to effectively avoid these failures.
The current setup is confusing, and, I guess, an inheritage from when
the same mozharness configs were used for buildbot and taskcluster jobs.
When mozharness calls tooltool_wrapper.sh, it doesn't set the
TOOLTOOL_CACHE environment variable from its configuration, like it does
for other commands. Instead, it passes the -c flag with the path from
its configuration. Then tooltool_wrapper.sh proceeds with ignoring the
-c flag and using TOOLTOOL_CACHE from the original environment,
inherited from the taskcluster setup script.
The upcoming new wrapper for tooltool in bug 1355731 doesn't keep this
confusing behavior, and respects the cache directory it's given on the
command line.
Now that most jobs run on taskcluster, and few use the same mozharness
config between buildbot and taskcluster, we can now go ahead and change
the TOOLTOOL_CACHE path in the mozharness config to match reality.
The list of files modified was generated from looking at
MOZHARNESS_CONFIG values in the full-task-graph.json file coming from
the Gecko decision task.
--HG--
extra : rebase_source : fe2baee48baffae52f738b4168f862c81370fcef
This patch allows the use of the flag '--jscov-dir-prefix' for mochitest plain tests to enable code coverage collection with the JS Debugger. It also enables the mochitest-plain tests for the linux64-jsdcov build platform.
MozReview-Commit-ID: 6RqMEZ1I0D7
--HG--
extra : rebase_source : 351754541801f69f7c54807f6bdd3a3d1baf9222
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
We add opt and debug mozconfigs that enable stylo.
We define 2 new mozharness build configurations for stylo builds. These
occur only on Linux64 for the moment.
The mozharness configs are mostly copypasta. This is how you do things
in mozharness land.
MozReview-Commit-ID: 99XNOymw9Dx
--HG--
extra : rebase_source : d89ddd907ed96697f62637859f6f719601e03b01
