To ease investigation of failures the gecko log should be streamed
to stdout so it will be part of the default log. It helps with
correlating tracing output with the appropriate test.
MozReview-Commit-ID: JnH64bhhtgk
--HG--
extra : rebase_source : b50707189c181a865ab66dac8b3cb4e258a8e427
This makes the changes necessary to use TestRunnerActivity when geckoview
is installed and requested, but we do not yet attempt to run any such
test tasks in automation.
Android jit tests are not ready to run yet: They may not run green, there are concerns about
capacity, etc. I am adding this support now to make it more convenient to debug on try.
--HG--
extra : rebase_source : 00bc5bf21fec3c130133b0de322b1f37250893c3
This is a new issue that gets linted with flake8 3.5.0. Basically you should
never use a blank except: statement.
This will catch all exceptions, including KeyboardInterrupt and SystemExit
(which is likely not intended). If a catch all is needed, use
`except: Exception`. If you *really* mean to also catch KeyboardInterrupt et
al, use `except: BaseException`.
Of course, being specific is often better than a catch all.
MozReview-Commit-ID: FKx80MLO4RN
--HG--
extra : rebase_source : 7c74a7d0d81f2c984b47aff3a0ee3448b791177b
In general, there is no simple mapping between apk name (geckoview_example.apk) and
package name (org.mozilla.geckoview_example). With bug 1434411, it will be relatively
easy to add or modify tasks to use a geckoview apk in taskcluster tests. At the
mozharness level, scripts are expected to expand mozharness configurations containing
"%(app)" into package names. For Firefox, android_emulator_unittest extracts and
reads package_name.txt, but there is no such file in the geckoview apk. In future
we might add package_name.txt to the geckoview apk, or possibly use a tool like aapt,
but for our immediate needs this simple hack does the job: If "geckoview" is in
the apk name, assume we are installing org.mozilla.geckoview_example.
When the emulator is in good shape, emulator verification on shutdown
only takes a few seconds. However, if the emulator is hung or otherwise
unresponsive, emulator verification can take several minutes. In the
pathological worst case, verification slows down the task enough to
exceed the task timeout, resulting in a failure that would otherwise
have been handled as a task retry. Emulator verification on shutdown
provides little value, so it is simply eliminated.
When MOZHARNESS_TEST_PATHS is set, the test suite mozharness scripts
will run the paths specified there instead of the normal chunking
and/or default manifest. Paths should be separated by a ':' character.
In the case of web_platform_tests.py, we have to make the test paths
relative to 'testing/web-platform'.
MozReview-Commit-ID: IHRXXi5mB4G
--HG--
extra : rebase_source : 17b31ec19a64ab16918d0bd80d19d9bb496cbe37
We use bogomips as a convenient indicator or emulator performance/health and
make that available in the android-performance.log artifact. When the task
times out, that artifact is not uploaded, leaving me curious about what the
bogomips were; let's dump it to the test log.
Check /proc/cpuinfo on android and extract the "bogomips" reading: If it is < 250, retry
the task, since there appears to be a higher probability of tests running too slowly
in such environments.
sutagent is no longer built or used; devicemanagerSUT is completely
unused. After this change, devicemanagerADB is the only implementation of
devicemanager, and test harness options like --dm_trans are eliminated.
