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
This patch provides the implementation that makes it possible to run the devtools test suite with the linux64-jsdcov build to collect js code coverage.
MozReview-Commit-ID: KFmFhKsDq5s
--HG--
extra : rebase_source : 78894caa6b45a0e43fd1a4c29190788523b10e12
This refactors the mozharness configs such that a specific flavor of an overall suite can still use the old
DesktopUnittestOutputParser. This is necessary because mochitest-jetpack still does not use the structured
logger.
MozReview-Commit-ID: E8EpSLH4xt2
--HG--
extra : rebase_source : be18e3e4aa1f693b563a82b90fdda2f93201d9ee
This accomplishes three things:
1) Easier to use CLI when running without the benefit of testing/mochitest/mach_commands.py
2) Guarantees these arguments are mutually exclusive
3) Simplifies a bunch of logic in the test harness
The primary motivation for this change is to slightly improve the UX when running mochitest
from a taskcluster interactive loaner. However, this is more of a bandaid solution that was
easy to implement before the proper fix in bug 1293259 can be landed.
MozReview-Commit-ID: IeHBGrJ0Sji
--HG--
extra : rebase_source : ba1b7e437881e363fe0051dccd3d732221311c59
This adds the ability to use the command line flag '--jscov-dir-prefix' to collect javascript code coverage from xpcshell tests and output it into the specified directory as a JSON file.
MozReview-Commit-ID: 3MZm73SNChL
--HG--
extra : transplant_source : c%9B%DE%A93w%E7%11%89%BE-%E8%D9%18%BC%12z%0A%0E%E4
This makes sure mozharness will always extract the mach binary and it will
be available when debugging interactive loaners.
MozReview-Commit-ID: BIXcCm4LzE2
--HG--
extra : rebase_source : 66cef916f7e86115b4f002ebad2550b70c0ae141
