This test would have caught the regression detected and fixed in bug 1512989.
It also sets up the scaffolding to add future tests to the reftest
manifestparser.
Depends on D14301
Differential Revision: https://phabricator.services.mozilla.com/D14302
--HG--
rename : layout/reftests/reftest-sanity/scripttest-pass.html => layout/tools/reftest/selftest/files/scripttest-pass.html
extra : moz-landing-system : lando
This will make it easier for new tests to get a handle on a RefTest instance so
they can do a wider variety of unittesting.
Depends on D14300
Differential Revision: https://phabricator.services.mozilla.com/D14301
--HG--
extra : moz-landing-system : lando
This was a regression from bug 1497339 which changed the location of
specialpowers in the objdir. While the reftest harness itself was changed, the
selftests weren't updated.
Only the local case was affected since the location of specialpowers in the
tests.zip remained the same. This explains why this wasn't caught in CI.
Differential Revision: https://phabricator.services.mozilla.com/D14300
--HG--
extra : moz-landing-system : lando
Moves mozleak to use structured logging. The logger gets two new
actions, mozleak_object to indicate the name of an object that leaked
in a specific process and mozleak_total to indicate the total number
of bytes leaked in a process.
The output from the TBPL formatter is
expected to remain near-identical to the previous output from the
logger, so there shouldn't be any effect on the ability to fail jobs
if there are leaks.
Additional features required by web-platform-tests are also added
here; the leak thresholds are passed to the logger for mozleak_total
and a list of any objects allowed to leak are passed for
mozleak_object, so that a log consumer may decide whether a leak is
unexpected. In addition, the scope attribute is used to specify the
set of tests (or other tasks) running at the time of the leak, which
may be used to associate a leak with a specific set of files.
MozReview-Commit-ID: 19FsMxVQExH
Depends on D12408
Differential Revision: https://phabricator.services.mozilla.com/D12409
--HG--
extra : moz-landing-system : lando
This removes the 'use-artifacts' mechanism in favour of fetches. There are a
few pieces here that need to land atomically:
1. Remove use-artifact related code
2. Call 'fetch-content' from the run-task script
3. Convert existing tasks on top of fetches (jsshell, python unittest)
4. Stop calling 'fetch-content' from toolchain setup tasks (as this now gets handled in run-task)
Depends on D2166.
Differential Revision: https://phabricator.services.mozilla.com/D2167
--HG--
extra : moz-landing-system : lando
This removes the 'use-artifacts' mechanism in favour of fetches. There are a
few pieces here that need to land atomically:
1. Remove use-artifact related code
2. Call 'fetch-content' from the run-task script
3. Convert existing tasks on top of fetches (jsshell, python unittest)
4. Stop calling 'fetch-content' from toolchain setup tasks (as this now gets handled in run-task)
Depends on D2166.
Differential Revision: https://phabricator.services.mozilla.com/D2167
--HG--
extra : moz-landing-system : lando
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
Instead of downloading the build artifacts (rather hackily) in moztest.fixtures, this now happens
directly in the taskgraph module via the run-task script.
For now extraction and setup happens in the task's command key. It might be a good idea to figure
out a syntax to tell run-task to do this extraction, e.g something like:
run:
using-artifacts:
build:
target.tar.bz2:
extract: true
path: /home/worker/build
name: firefox
But for now I wanted to avoid this extra complexity, so maybe it could be done in a follow-up.
MozReview-Commit-ID: KOhFFpFdP7Y
--HG--
extra : rebase_source : dcea36661fa9c6442c76c850ccc67f8f6d924fda
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
Currently reftest.jsm uses logger.testEnd(..) to log all kinds of different
potential failures, from proper test failures to harness issues. This means
there are all kinds of edge cases that would cause multiple testEnd messages to
get logged, something the structured log protocol is supposed to prevent.
This modifies the reftest harness to instead use testStatus for everything. The
testEnd call will always be logged with status "OK". This required some changes
to the reftest formatter and reftest selftests.
MozReview-Commit-ID: 8RxsmHW49oy
--HG--
extra : rebase_source : 2f53e63f00bfc5e0e751b0f2bb3dc67477dc07eb
This installs specialpowers in the test runs so we can trigger crashes/assertions.
MozReview-Commit-ID: 8878OcHv8hU
--HG--
rename : testing/mochitest/tests/python/files/leaks.log => layout/tools/reftest/selftest/files/leaks.log
extra : rebase_source : cee417db30ff76364fa3212a65b2d537c97cc8bd
This just adds two basic tests, one for a passing test and another for a
failing one. In mochitest, we use privileged APIs to also tests crashes,
assertions, asan and leaks. But these APIs aren't available to reftests
so I'm not sure how we can test these things.
I figure it's not worth holding the framework up on this though, I'll file
a follow-up to figure out something to do for that.
MozReview-Commit-ID: 59TSbsugT5T
--HG--
extra : rebase_source : 72ecd817017c8b7d55eab879db4f6ad5fecc54c0
