In addition to saving the log level of 'process_output' messages, this will also start passing 'log'
messages through the error lists. This means mozharness will start using 'log' errors when determining
the tbpl_status and worst_log_level.
MozReview-Commit-ID: CZnH6aI1Wo0
--HG--
extra : rebase_source : 55c74bfa2afdf6d7b510b351ad657ecd615d4347
Add configurations for building and uploading AArch64 Nightly builds, in
tier 1 and without artifact support for now.
As for not denoting AArch64 builds as "api-21", I don't really think we
will split AArch64 the way we split ARMv7 before. Originally, we split
into API 9 and API 11+ because of lots of "constrained" devices that
were stuck with API 9. We made an API 9 APK in order to lower our
footprint on those devices. That probably will not be a problem for
AArch64, because devices with API 21+ and AArch64 support are usually
more than capable for running Fennec. Secondly, it was a big change for
Android going from API 9 to API 11+, so we saved quite a bit of
code/resources when we stripped out API 11+. I don't see such drastic
changes going from API 21 to upcoming versions, so even if we did split,
I don't think it'll get us much benefit.
MozReview-Commit-ID: 7N7Slv1pPgb
This updates geckodriver's cargo lockfile,
testing/geckodriver/Cargo.lock, with the exact crate versions available
under third_party/rust. This will ensure geckodriver is built using the
correct in-tree crate dependencies.
MozReview-Commit-ID: HtPohwW6uN0
--HG--
extra : rebase_source : cdafc425e572494550ce81d6d8c612496fcaab82
geckodriver is the Mozilla implementation of the WebDriver remote
control interface for Gecko, and provides an HTTPD proxy that
translates the WebDriver protocol to Marionette.
Building this as part of the Firefox build will allow us to run
WPT WebDriver tests to verify our implementation of Marionette and
geckodriver. It also makes it less painful to make changes across
projects.
This change will cause the geckodriver program to be built as part
of regular Firefox builds, except on macOS and Android, and when artifact
builds are enabled.
RUST_PROGRAMS in cross-compile environments cause the wrong linker to
be used. When this bug is fixed, we should be able to enable building
of geckodriver on macOS. This work is tracked in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1329737
On Android, we may one to build a binary for the host system to use
(x86_64), instead of an ARM binary for the emulator.
MozReview-Commit-ID: FG5tmPv4iut
--HG--
extra : rebase_source : 091728fd2582458325689fc6e3d8b317428802d8
Several mochitests call `assertSnapshots`, which prints a reftest-like output
for use with the reftest analyzer. Update these lines to check failure patterns
before printing, like the regular assertion methods do.
MozReview-Commit-ID: CfChoar7bp8
Several years ago there was a single zip file for all test files. Clients
would only extract the files they needed. Thus, zip was a reasonable
archive format because it allowed direct access to members without
having to decompress the entirety of the stream.
We have since split up that monolithic archive into separate,
domain-specific archives. e.g. 1 archive for mochitests and one
for xpcshell tests. This drastically cut down on network I/O
required on testers because they only fetched archives/data that
was relevant. It also enabled parallel generation of test archives,
we shaved dozens of seconds off builds due to compression being
a long pole.
Despite the architectural changes to test archive management, we
still used zip files. This is not ideal because we no longer access
specific files in test archives and thus don't care about single/partial
member access performance.
This commit implements support for generating tar.gz test archives.
And it switches the web-platform archive to a tar.gz file.
The performance implications for archive generation are significant:
before: 48,321,250 bytes; 6.05s
after: 31,844,267 bytes; 4.57s
The size is reduced because we have a single compression context
so data from 1 file can benefit compression in a subsequent file.
CPU usage is reduced because the compressor has to work less with
1 context than it does with N. While I didn't measure it, decompression
performance should also be improved for the same reasons. And of course
network I/O will be reduced.
mozharness consumers use a generic method for handling unarchiving.
This method automagically handles multiple file extensions. So as long
as downstream consumers aren't hard coding ".zip" this change should
"just work."
MozReview-Commit-ID: LQa5MIHLsms
--HG--
extra : rebase_source : cd029cdbbcccc1d16f03d63a5f1fdf60be5db4fd
extra : source : a0e257e346ccf3c1db332ec5903241f4eeb9a7ee
If the browser is in fullscreen mode and Set Window Rect is called
we need to exit fullscreen mode and then continue to manipulate the
browser.
As described in https://w3c.github.io/webdriver/webdriver-spec.html#set-window-rect
Step 10
MozReview-Commit-ID: 5ixhGOXVBE4
--HG--
extra : rebase_source : be2b8b6da5cf78c6263502a6cb422e2de81c742d
If the browser is in fullscreen mode and Set Window Rect is called
we need to exit fullscreen mode and then continue to manipulate the
browser.
As described in https://w3c.github.io/webdriver/webdriver-spec.html#set-window-rect
Step 10
MozReview-Commit-ID: 5ixhGOXVBE4
--HG--
extra : rebase_source : be2b8b6da5cf78c6263502a6cb422e2de81c742d
