This allows syntax like --try-test-paths web-platform-tests-reftests:path/to/test
MozReview-Commit-ID: uAet1ilPVy
--HG--
extra : rebase_source : 447277e47701435186ad87dfc089bd21f2bd1907
Flip around the logic of bug 1356122, so that the default from Stylo runs is the
parallel traversal, but we can opt in to single traversal as desired.
This ensures that for testing on other desktop platforms, we use parallel
traversal as the default.
MozReview-Commit-ID: KoBe1ltHP52
--HG--
extra : rebase_source : ad96f24c9760544c5812060f26e9ca18e5bf2ba8
Bug 1374940 adds a MOZ_TOOLCHAINS environment variable with a list of
path@task-id strings, where task-id is corresponding to the (possibly
optimized) toolchain job, and path corresponding to the
toolchain-artifact defined for that toolchain job.
We want to use that to pull artifacts instead of tooltool packages.
--HG--
extra : rebase_source : 277daa2c83d6d197975cb4ef36ee131176afa992
Land date changes to support windows nightlies onto central
MozReview-Commit-ID: 4Nxhbutjhfu
--HG--
extra : rebase_source : 2a180738584d6de77fe1b8fe81ecb004582000c5
Land date changes to support windows nightlies onto central
This patch also allows us to not reconfigure to run repackage on windows, which saves us both in potential pain points and execution time.
MozReview-Commit-ID: xnz98Z5N06
--HG--
extra : rebase_source : 1630a3b6b646a83abeb05000e77e0e3c3238250b
Land date changes to support windows nightlies onto central
This will be needed for windows, because if the artifact is output to a folder that is, itself, an artifact folder, we'll end up publishing the named artifact twice. Which is unhelpful.
MozReview-Commit-ID: 5S6SNul6Fm9
--HG--
extra : rebase_source : 5501d8d757c7408c9dd014bc04a8d36429bdd9b5
Added cli_script attribute to TelemetryClientTests due to test failure
Added telemetry test requirements file to /testing/config
Added mozharness script to run telemetry tests from checkout
MozReview-Commit-ID: AJKM7b1OcVW
--HG--
extra : rebase_source : 8147ad3decaa94c28ba48b87310b4a00d5a90fd2
Added cli_script attribute to TelemetryClientTests due to test failure
Added telemetry test requirements file to /testing/config
Added mozharness script to run telemetry tests from checkout
MozReview-Commit-ID: AJKM7b1OcVW
--HG--
extra : rebase_source : 8147ad3decaa94c28ba48b87310b4a00d5a90fd2
`try-test-paths` is set up to map anything under testing/web-platform
to the web-platform-tests flavour. By default, the web-platform-tests flavour
refers to the testharness test type for wptrunner, so we need to account for
reftest and wdspec test types.
This change causes mozharness to omit the test-type argument to wptrunner when
try-test-paths is being used, therefore making wptrunner determine the
appropriate test type for each requested test.
MozReview-Commit-ID: 7TDAShdDM4g
--HG--
extra : rebase_source : fde6ec219f574cd1e536764c0128a6816834f533
Support OSX Signed nightlies (in the complete.mar too)
MozReview-Commit-ID: 6iPrPhjj34g
--HG--
extra : rebase_source : 55a6bcf1910f1cae084cf32f6cf47ecf44b500aa
As of bug 1373150, l10n repacks do not require a anything to compile, so
they can stop downloading most toolchains from tooltool. However some
tools are still required, such as mozmake on Windows and DMG-related
tools on cross OSX.
--HG--
extra : rebase_source : f46e851c7941491530ce65490d0cfce4f9f02e35
In automation we should combine the standard logging and
the gecko log by default to ease the investigation of test
failures. It will also provide crash/assertion output
without having to search for it in other log files.
Also the custom error list has been replaced with the
default base and harness error lists as used by other
harnesses, which prevents false assumptions by the parser
when the trace log contains returns of expected errors.
MozReview-Commit-ID: 1rQ6maOqD3V
--HG--
extra : rebase_source : 77e94ffc6b77ac0467214321ed566f58c4e46f0e
(For Landing more OSX Nightly Support from date to central)
MozReview-Commit-ID: FSbQZ1Fbdcs
--HG--
extra : rebase_source : 3651dd368f032ae9f17cba42010902f850a64700
(For Landing more OSX Nightly Support from date to central)
MozReview-Commit-ID: FSbQZ1Fbdcs
--HG--
extra : rebase_source : 3651dd368f032ae9f17cba42010902f850a64700
Allow running |mach wpt| on one click loaners in order to run
web-platform-tests tests.
This implementation is just like the one for other testsuites using
thee packaged tests rather than the checkout that we get with wpt, at
least on Linux. That's also where the tests run from so it seems
reasonable for now. Moving to the checkout in the future could remove
some of the logic here by using a fake mozbuild environment so that
the testsuite itself doesn't have to implement anything much.
MozReview-Commit-ID: CaewrdjJ2ef
--HG--
extra : rebase_source : 491b8014d48f06ff5bd41b28cc985608981fbdf4
For a while now it has been making the content process sandbox less strict.
MozReview-Commit-ID: Am6fGzViaLk
--HG--
extra : rebase_source : 0bc037f205896c866559a7ab1f7e2c042c3142db
With multiple types of repackaging, it will be simpler to manage the
various commands if they are organized as sub-commands. This way the
different repackage types can take varying arguments, and we don't have
to guess on the repackage type based on the output filename.
MozReview-Commit-ID: BknRPAwFG5H
--HG--
extra : rebase_source : e74a9776a73791e41ada4038a8bb2ddd243d0de8
This enables all test suites on linux64-ccov except for the talos test suite (more work needs to be done), spidermonkey tests (more work needs to be done), and the mochitest-valgrind test suite (not going to run linux64-ccov).
MozReview-Commit-ID: 6vYV89CH8TB
--HG--
extra : rebase_source : 2c2c22a2ffc0b431b24e0ee32dca046a11470d3c
Instead of fetching geckodriver from tooltool, we ask mozharness to
pick up the geckodriver binary from the common test archive. As it
is packaged under /bin along with other test-relevant binaries such as
wptserve, we can retrieve it from the abs_test_install_dir.
It would also be possible to use ScriptMixin.query_exe for this purpose
after specifying the binary in the "exes" section of the different
mozharness configs, but this seems needlessly complicated.
Because we also do not yet have geckodriver on all platforms, we only
want to look for it if requested to run the wdspec test type.
MozReview-Commit-ID: 7jLuBeDiQNE
--HG--
extra : rebase_source : ea8c1be063be0f40ff4c8f8c3a77b1b57580829d
mozharness is Python. self.query_exe('python') could resolve to a
different Python interpreter from what mozharness is running as.
In order to promote consistency, always invoke python processes with
the Python being used to run mozharness.
In some cases, this may cause former `python` processes to run as
Python 2.7 instead of 2.6 (since `python` resolves to a 2.6 interpreter
on many systems). It may also result in slightly different Python
binaries being used. But I think sharing interpreters between the
mozharness script and launched processes is logical. So if this causes
problems, I'd like to flush those out.
MozReview-Commit-ID: KfawUvT5jgW
--HG--
extra : source : b6f04897fdda51e42612617a89a93f696edbdf92
extra : amend_source : 32dafc7c9dc2cec80bc289bd1a17cdbb8cde5025
Previously, mozharness defined a separate action to collect build
metrics. This required the script and/or config to define that
action.
Metrics collection for CI is important. So it should be enabled by
default.
This commit changes the "build" action/method to always call the
metrics collection function after successful build. References to
the "generate-build-stats" action have been removed because it is
redundant.
A side-effect of this change is we may generate build metrics where
we weren't before. This could lead to e.g. duplicate entries in some
Perfherder series. Let's see what breaks ;)
MozReview-Commit-ID: 42UQI5YQTMC
--HG--
extra : rebase_source : c57dc9ec6ac46003384edff098a0ad81c75539b7
extra : source : c9812dd7d27a174c0ee46d44ec595fbe29c9e1db
mozharness is Python. self.query_exe('python') could resolve to a
different Python interpreter from what mozharness is running as.
In order to promote consistency, always invoke python processes with
the Python being used to run mozharness.
In some cases, this may cause former `python` processes to run as
Python 2.7 instead of 2.6 (since `python` resolves to a 2.6 interpreter
on many systems). It may also result in slightly different Python
binaries being used. But I think sharing interpreters between the
mozharness script and launched processes is logical. So if this causes
problems, I'd like to flush those out.
MozReview-Commit-ID: KfawUvT5jgW
--HG--
extra : rebase_source : 8babadc464ea4d8971e091d5446d86d2630e07b9
The main motivation behind this change is that going towards toolchain
tasks hooked up in the task graph (bug 1313111), we're going to end up
with jobs using both taskcluster toolchain job and tooltool artifacts
for their toolchain needs. With the current setup, this means the
toolchain dependencies will be spread between taskcluster task graph
definition and mozharness configuration.
It also makes things more complex to provide a command that pulls the
right toolchains from both taskcluster and tooltool (bug 1356529),
because one needs to find and parse the mozharness config (which also
happens to be python code that uses platform-specific things, so e.g.
reading windows mozharness config fails on other platforms).
All in all, moving the tooltool manifest path to the taskcluster task
definitions would make things simpler, and would also allow make patches
switching from tooltool to taskcluster artifacts more straightforward to
validate.
But since some build types still run on buildbot, we'll have to keep
part of the current setup using mozharness configs. So we allow to
override the tooltool manifest path from the environment, and we'll rely
on taskcluster task definitions being able to set environment variables.
Actually moving the relevant tooltool manifest paths from mozharness
config to taskcluster task definitions is left for a followup.
Another followup is to move the tooltool manifest paths declared in
some ad-hoc build scripts to taskcluster task definitions as well.
The immediate need for this, though, is to allow to have duplicated jobs
that only differ in their tooltool manifest, without duplicating a
complete mozharness config that will end up stale (the goal being that
really only the tooltool manifest differs, even when the original jobs
change).
--HG--
extra : rebase_source : 3622779926b1b5e86e809c1f6422bd55ef64eed7
