ensuring moz.build files have BUG_COMPONENTS for all files
in the testing/ subdirectory is a win. There are a lot of
older files and some files used in many harnesses. If the
files are primarily used for mochitest, they are associated
with the testing::mochitest component, otherwise I chose
the testing::general component.
There is an exception web-platform-tests, these have many
test files that need to be matched to proper components.
MozReview-Commit-ID: IIv9W2kEqeN
Registered callback handlers for tests should receive the correct
test status when the test has been finished, and not always "Error".
This change allows those callbacks to run specific code for individual
test results, eg. only do screenshots for failures.
MozReview-Commit-ID: FfbCRR0Jvjb
--HG--
extra : rebase_source : c73253acbb666ca62b23f806145c20f0a70c934c
Registered callback handlers for tests should receive the correct
test status when the test has been finished, and not always "Error".
This change allows those callbacks to run specific code for individual
test results, eg. only do screenshots for failures.
MozReview-Commit-ID: FfbCRR0Jvjb
--HG--
extra : rebase_source : 98c69eea450f35312fd43bb7237a9d00e90636c4
This fixes a regression when switching to the StructuredOutputParser in mozharness.
Previously, mozleak was relying on the string "TEST-UNEXPECTED-FAIL" to turn the jobs
orange, but it was doing so at the "warning" level. The StructuredOutputParser requires
the "error" level to set the appropriate tbpl_status.
MozReview-Commit-ID: 9u9mwqrkA6E
--HG--
extra : rebase_source : d31ece08232a87713702e713076071fa10fb8324
This fixes a regression when switching to the StructuredOutputParser in mozharness.
Previously, mozleak was relying on the string "TEST-UNEXPECTED-FAIL" to turn the jobs
orange, but it was doing so at the "warning" level. The StructuredOutputParser requires
the "error" level to set the appropriate tbpl_status.
MozReview-Commit-ID: 9u9mwqrkA6E
--HG--
extra : rebase_source : 4d975e481c8257b178a145497bc53eabc28ed182
This is intended as a structured replacement for the assertion checks
that previously used unstructured logs. It adds a log action
assertion_count, which takes the actual number of assertions observed
during a test, the minimum expeced number and the maximum expected
number. It also updates the reftest harness to use this logging.
MozReview-Commit-ID: JgjLlaYuvSG
The only consumer of `mozrunner.devices.base.Device.setup_port_forward`
was Marionette, which now uses `mozdevice.DeviceManagerADB.forward`
directly.
MozReview-Commit-ID: 72ROrOixKvM
--HG--
extra : rebase_source : f998e6c37161f851da450bd98ee27ba04a50f16f
This deprecates PYTHON_UNIT_TESTS and replaces it with PYTHON_UNITTEST_MANIFESTS.
In the build system, this means python unittests will be treated the same as all
other test suites that use manifestparser. New manifests called 'python.ini' have
been created for all test directories containing python unittests.
MozReview-Commit-ID: IBHG7Thif2D
--HG--
extra : rebase_source : 11a92a2bc544d067946bbd774975140147458caa
The mozbase unittests don't use mozunit, so their output is confusing in the log.
This makes mozbase output consistent with the rest of the python unittests.
MozReview-Commit-ID: AIs5mza8Rn6
--HG--
extra : rebase_source : 10f65e612f5b3cebb921c47699f5a8be7cd2ba5a
The mozsystemmonitor test is under mozsystemmonitor/mozsystemmonitor/test instead of
mozsystemmonitor/tests like all the other mozbase modules.
MozReview-Commit-ID: AIs5mza8Rn6
--HG--
rename : testing/mozbase/mozsystemmonitor/mozsystemmonitor/test/test_resource_monitor.py => testing/mozbase/mozsystemmonitor/tests/test_resource_monitor.py
extra : rebase_source : dde714fb9212f19d1f8ba566f574bd7e9d7c4030
For some reason calling os.getpgid(proc.pid) in this bug results in an OSError "No such process"
on OSX. This bug is starting the ProcessHandler from a concurrent.futures Thread, that must be
somehow related.
I tried debugging this, but couldn't figure out why this is happening. However, the pgid is not
needed for this use case, and simply ignoring the error works. We also ignore this very same
exception when calling os.getpgid elsewhere in mozprocess, so there must be some weird OSXism
happening.
MozReview-Commit-ID: 2YXhBaORC5s
--HG--
extra : rebase_source : 120e4bff7ef29d2a0ad1e3bdd2df11b8b682d981
Adapt check_for_crashes() for latest mozcrash changes, which returns the number of crashes for both log_crashes()
and check_for_crashes() now. Also the runner should accumulate the number of crashes so it will be known at any
time how many times the process has been crashed.
MozReview-Commit-ID: Dl9FlH1TalH
--HG--
extra : rebase_source : b27895482fcad099cf4fcfc01a65fe0fbc5243e3
Currently check_for_crashes() behaves differently compared to log_crashes(), whereby it only returns a
boolean if a crash has been detected but not the amount of crash reports found. We should make sure that
both methods behave the same. Given that this change might affect consumers, we should have a major version
bump for the new release.
MozReview-Commit-ID: LiPaozJL5NF
--HG--
extra : rebase_source : d4392207399a1383a20e037bcf73f44bf3c36c7d
This causes consumers managing defaults themselves to fail to find a default
subsuite for tests, because the manifestparser will have provided a blank
default value by the time they incorporate defaults into a test definition.
This patch removes the provided defaults and updates a number of places assuming
the 'subsuite' field is always present.
MozReview-Commit-ID: 1jPy52VmEPr
This causes consumers managing defaults themselves to fail to find a default
subsuite for tests, because the manifestparser will have provided a blank
default value by the time they incorporate defaults into a test definition.
This patch removes the provided defaults and updates a number of places assuming
the 'subsuite' field is always present.
MozReview-Commit-ID: 1jPy52VmEPr
--HG--
extra : rebase_source : be7a2504af6853abb1bc532a058738f33d8dcbee