Also include webgl2-deqp, which we would like to run eventually, but not yet.
MozReview-Commit-ID: CY4hYCI95ws
--HG--
extra : rebase_source : 9973df0f905bb65d2e8b8c66a6a57e8869e527c1
Also include webgl2-deqp, which we would like to run eventually, but not yet.
MozReview-Commit-ID: FDWdu1J0end
--HG--
extra : rebase_source : a47d88cb2c5eb82e4dfaa9e58d76acbf0736d35d
Summary: Bug 1469933 When using ./mach run --debugger=windbg, use the x64 version of WinDBG r?ted
Reviewers: ted
Reviewed By: ted
Bug #: 1469933
Differential Revision: https://phabricator.services.mozilla.com/D1730
--HG--
extra : amend_source : 67de4dae3a129df77976da82005acb47ad64b5ed
Start Firefox with -foreground and -no-remote arguments if they
have not already been given by the user.
-foreground will ensure the application window gets focus when
Firefox is started, and -no-remote will prevent remote commands to
this instance of Firefox and also ensure we always start a new instance.
MozReview-Commit-ID: LGEqgyHYapc
--HG--
extra : rebase_source : 50054e89106421dc6b43bc1f109dc75db37dfd2d
The std::process::Command's stdout and stderr is configured earlier in
::start(), and resetting it to a static value below would invalidate the
configured stdout and stderr stored in FirefoxRunner::stdout and ::stderr.
We did not notice this bug because geckodriver does not
yet use this feature. It was added as a precursor for
https://bugzilla.mozilla.org/show_bug.cgi?id=1466573.
MozReview-Commit-ID: CmwqCZpEMqq
--HG--
extra : rebase_source : 209d7cdde8b05db9b7e6f02b221c32a436f2ecdf
Bug 1464995 broke mozrunner on macOS, but we did not notice because
geckodriver is not compiled on macOS. This fixes the build.
MozReview-Commit-ID: GnvZTT30wHG
--HG--
extra : rebase_source : 6e5b5b37d0c962c75a2a4b41c004f9cf47c2e8a2
mach android-emulator currently supports 6 different avds; I am struggling to maintain
that many configurations. I don't see a lot of value in keeping both 6.0 and 7.0,
and Android 6.0 is not as popular as 7.0. Let's remove 6.0, encouraging 7.0 as an
alternative; same for x86-6.0 -> x86-7.0.
mozrunner fails to locate the correct binary if Firefox is found
under a "firefox" or "firefox-bin" (depending on the system)
because it thinks the parent directory is the executable.
On Unix systems, mozrunner also falsely reports non-executable
files as valid binaries.
This patch introduces a new mozrunner::path module that provides
two functions: one for searching the system path for a binary by a
given name, and another for checking whether a path is an executable
binary file.
MozReview-Commit-ID: 6N06CXZZWqd
--HG--
extra : rebase_source : dbcb4d6d8478bafc23c1aa2a3081589074908bbc
Removes an unnecessary as_ref() cast, a path coercion, and replaces
try!() with ?.
MozReview-Commit-ID: ASd9kNxDZ3n
--HG--
extra : rebase_source : fa88def64fc3c7ea4520403bfc7b5c391d7f83da
The method we use to find the Firefox binary varies from platform
to platform. It can be useful to document how each of the system
specific implementations are meant to work.
MozReview-Commit-ID: 4SrNmlp3AdS
--HG--
extra : rebase_source : f1d54548edb416912af3a0a6d41188d0640a3ffb
Parent tests may also have stacktraces and this patch prints and
formats them the same way we do for subtests' stacks.
MozReview-Commit-ID: 64gfPWuQnHd
--HG--
extra : rebase_source : 6a37eda231091d66a92226c3ebadb7b7980766be
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
Before this patch, the x86-6.0 and x86-7.0 Android emulators were
unusable on macOS (tested 10.13.4 High Sierra).
The emulator's UI appears (but with black screen), and the launcher
icon in the dock has a default folder icon instead of the emulator.
When I use "mach android-emulator --version=x86-6.0 --verbose",
then the full emulator command is printed. I discovered that
using the newer QEMU 2 engine ("-engine qemu2") fixes the issue, and
that the emulator launches as expected. This option is documented at:
https://developer.android.com/studio/run/emulator-commandline
However, when I modify the source of these commands, then the emulator
fails to start (as before). This is caused by the setpgid call via
preexec_fn in testing/mozbase/mozprocess/mozprocess/processhandler.py .
Passing ignore_children=True to ProcessHandler avoids the setpgid call
and allows the emulator to be used as expected on macOS.
The effect of not using setpgid is that the spawned process will not
be put in the process group of the "mach" Python script. This is not
a big deal. I can confirm that the emulator can still be killed by
quitting or force-quitting it, and did not experience other issues.
MozReview-Commit-ID: 4AKVqtwIoCj
--HG--
extra : rebase_source : df6615a32de666d0f9d4f27c1c6f462120364ee2
Following the move to use cargo worktrees in central, the .gitignore
file for mozversion is not used anymore since we no longer generate
testing/mozbase/rust/mozversion/target on building.
MozReview-Commit-ID: 72geBjNxjZl
--HG--
extra : rebase_source : d7f11b33c91407e97416344ca1a2d0f06aa573d3
In bug 1440714, mozdevice had its version bumped to 1.0.0, outside of the required
range in mozrunner's deps, causing in-tree breakage. Subsequently, I changed mozrunner's
dep list to allow for mozdevice 1.0.0, and released mozdevice 1.0.0 on pypi. Now I need
to update mozrunner on pypi with the updated deps, so require a mozrunner version bump.
This is mainly to pick up bug 1448221 since the version of mozprofile on pypi can't
install addons with nightly anymore (due to the profile/extensions/staged directory
not being supported).
But since that change I've also landed several backwards incompatible API changes to
how addons are installed.
Bumping to 1.0.0 because I'd like us to start (attempting) to follow SemVer:
https://semver.org/
MozReview-Commit-ID: FDIPqNnSKJ6
--HG--
extra : rebase_source : 4e083b77802c97b85436410b40225ad234b9e7fb
Neither package has any backwards incompatible changes. However, I decided to
bump the major version for mozrunner as this is the first time it's switching
to SemVer (mozprofile already made the switch). It seemed cleaner to have the
switch happen after a major bump.
In both cases, I've added major version upper limit guards to each dependency.
This way we won't break these packages in the future when we land backwards
incompatible changes to the dependendencies.
MozReview-Commit-ID: 5SIpMGTS3cc
--HG--
extra : rebase_source : 43ab4c9f3af50eb82a22ec3112e5b56fe703dbc6
In Chrome it doesn't seem to be possible to install extensions by dropping them
in the profile directory. Instead we use the --load-extension command line
argument. To that end the ChromeProfile uses a 'dummy' AddonManager() class
that is actually just a list with an 'install' method. Mozrunner will be
responsible for building the command line based on this list.
We also need a few other command line arguments to build and create a temporary
profile directory.
MozReview-Commit-ID: HC2p2ZZMl66
--HG--
extra : rebase_source : 2d748893e8530a312afb5d8b1442a4c29f93caf1
In addition to Profile, this will be implemented by the ChromeProfile class in
the next commit. This way we can test for 'isinstance(profile, BaseProfile)'
when we just want to test for a profile regardless of application.
Ideally I would have preferred 'Profile' itself to be the base class (and co-opt
FirefoxProfile to be the new defacto class for firefox profiles), but this would
break backwards compatibility.
MozReview-Commit-ID: 6TTFq2PQOGM
--HG--
extra : rebase_source : 57651887061ec52b176729109271ee2e23552cdb
This will make it a bit easier for consumers to create a profile instance. They
can just call:
profile = create_profile('firefox', prefs=...)
Instead of needing to first find the class, then do the instantiation.
MozReview-Commit-ID: 7FqAGsSyZVe
--HG--
extra : rebase_source : 3172189618d6948959edfc61d6782373d27a2cbb
This is a much cleaner and easier to understand test format. It will also make
it easier to add tests for the upcoming ChromeProfile changes.
MozReview-Commit-ID: DizKGt0qkPF
--HG--
rename : testing/mozbase/mozprofile/tests/addonid.py => testing/mozbase/mozprofile/tests/test_addonid.py
rename : testing/mozbase/mozprofile/tests/bug758250.py => testing/mozbase/mozprofile/tests/test_bug758250.py
rename : testing/mozbase/mozprofile/tests/permissions.py => testing/mozbase/mozprofile/tests/test_permissions.py
rename : testing/mozbase/mozprofile/tests/server_locations.py => testing/mozbase/mozprofile/tests/test_server_locations.py
extra : rebase_source : 07953fd02a8592ed31e1972d646ff93bfd25d80b
This allows consumers to bootstrap Chrome with mozrunner. For now the profile implementation
is just an empty class but this will be expanded in a future commit.
MozReview-Commit-ID: 1Z14FudH0JJ
--HG--
extra : rebase_source : b593965a6bd725b133adf42ff31d61726bcff520
This will make it easier to add the ChromeRunner tests in the next couple of
commits.
MozReview-Commit-ID: 2Nfz92FStSX
--HG--
rename : testing/mozbase/mozrunner/tests/mozrunnertest.py => testing/mozbase/mozrunner/tests/conftest.py
extra : rebase_source : 27837679b744e7f765fdb2d4f43d4bab14fb2dc0
This is a leftover artifact from the B2G days that isn't being used anymore.
MozReview-Commit-ID: FZoTwHltmAG
--HG--
extra : rebase_source : 455450f360fa222522f365118d1e687528e08b69
This isn't strictly related to this bug, but it is a change made to mozbase in
the raptor repo that is worth backporting here. Figured it's easiest to land it
alongside the other mozbase backports.
MozReview-Commit-ID: DW7I2zKZZNk
--HG--
extra : rebase_source : a000d27774f224d37f981d6683d96c65846b8a32
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.
I missed a couple of references in cleanup code. This wouldn't have caused any
failures but might result in addons not being cleaned up properly.
MozReview-Commit-ID: BX0oX2GRGWT
--HG--
extra : rebase_source : 2193adb4e96b8e70faa6ffb1afd6db698b10ad2d
The patch correctly marks the delimiters for the tree output
as Unicode, and also updates mozprofile to correctly serialize
the Profile object when str() is used.
MozReview-Commit-ID: AjUHa6zGHQe
--HG--
extra : rebase_source : d4fa6c5db91184dee6a2abe788aa23d0c6255be6
While we are removing a bunch of stuff and breaking backwards compatibility, I
figured this would be a good time to also change some of the APIs. These APIs
aren't used much in mozilla-central (and this patch updates the few places that
do).
This rolls the 'install_addons()' and 'install_addon_from_path' method into a
single 'install' method. This install method can accept a string or list of
paths to an individual addon (directory or .xpi), or a directory containing
addons.
This also renames Profile.addon_manager to Profile.addons, which reads better.
MozReview-Commit-ID: 7vDPnG4cKqu
--HG--
extra : rebase_source : 62f8613b9824e06e698d5af8dcbb4bcb07b8079e
This is another seemingly unused feature in mozilla-central.
Being able to download addons in AddonManager is a violation of the single
responsibility principle. If consumers *really* need to download addons, they
can easily do so with requests and then pass the file path in to AddonManager
like normal. There's no need to have this baked into AddonManager itself.
MozReview-Commit-ID: IorG0foiHfT
--HG--
extra : rebase_source : 27b4162d9adfb986c2b9822c12b6abc5a2561a9a
This feature isn't used anywhere in mozilla-central that I can tell. Because
using a manifest is the only way to install an addon from AMO, that ability has
also been removed with this commit.
MozReview-Commit-ID: BNFGPWdo96t
--HG--
extra : rebase_source : 9bc7c9c7e91b01b71082f763fb6e621c430de808
The build job on Windows sets the MINIDUMP_SAVE_PATH env variable,
and because it isn't unset mozcrash copies all created minidump
files from unittests to the "public/build" folder, which then
get uploaded as artifacts.
MozReview-Commit-ID: 6JNnRZGlOj3
--HG--
extra : rebase_source : c148e5a8ac4439ca0f4e66ee649b45ceb7b1bc60
If a ProcessHandler instance has been created, but mozprocess fails
to start the child process, a dangling process_handler instance is
attached to the runner instance. This should be avoided, and a
RunnerNotStartedError has to be thrown.
MozReview-Commit-ID: LgNFVaT9qVs
--HG--
extra : rebase_source : c06aef08d7619ac9d3fe94ad29bdae06f0f79364
Without encoding the key and value of environment variables as UTF-8
for non-interactive sessions "subprocess.Popen()" and specifically
"os.execvpe()" will fail.
MozReview-Commit-ID: 9lO562XnDZx
--HG--
extra : rebase_source : bba542648b6050d0e9f628c95b658c3a546d2b5d
The build job on Windows sets the MINIDUMP_SAVE_PATH env variable,
and because it isn't unset mozcrash copies all created minidump
files from unittests to the "public/build" folder, which then
get uploaded as artifacts.
MozReview-Commit-ID: 6JNnRZGlOj3
--HG--
extra : rebase_source : a139221b810e1b38082d5676b67583269802b7e9
One change since 0.6.0, which is a regression fix for a fallout
from bug 1443853.
MozReview-Commit-ID: 56GbEV4HM4v
--HG--
extra : rebase_source : 0e14fa63f00f1661cae01a10c76c2813d349ba1b
std::process::Child::kill() will return Err if the process has
already exited. The assumption in bug 1443853 was that calling
::kill() would consistently return the std::process::ExitStatus
was the process already dead.
This patches the regression from bug 1443853 by employing
Child::try_wait() in a loop. When the process gives some exit status,
this is return directly without relying on Child::kill() as before.
If the process has not exited and the timeout has elapsed, we kill
the process and return its return value. If the process has not
exited but the timeout duration has not elapsed, we wait 100 ms as before.
MozReview-Commit-ID: 4VENbrKtcEh
--HG--
extra : rebase_source : 7f27ed057da740306367ef2b6a87f8ac6a242541
This consolidates the printing of status logs, which was previously handled
differently in 3-4 places. This also fixes a few of the annoyances listed in
the bug 1445624 description. Finally this also fixes a few edge cases that I
noticed when writing the tests.
MozReview-Commit-ID: APudT8yBqVS
--HG--
extra : rebase_source : 943a71c762dd27a7f7ebea86d467e81a0b27d400
extra : source : 61ba86fc1366a62a429a7daab7d6b1c198c69593
This adds a basic test for the mach formatter. This will ensure that changes to
this format are intentional. It will also make it easier for reviewers of these
changes to see a diff of the old vs new format.
MozReview-Commit-ID: LBSfdyvOPVV
--HG--
extra : rebase_source : 5529ad1f03306dcf867d88af579b69d6005091c0
To let mozcrash handle minidump files located in profile paths
with unicode characters, support for that has to be added. It
also applies to the locations for the stackwalk binary, minidump
save path, and symbols.
MozReview-Commit-ID: EROVmK21a5Y
--HG--
extra : rebase_source : 67092e6164eb0e46decd24b2da1490ffefb4d5d7
Switch to the pytest framework to benefit from its rich
feature set for creating Python test.
MozReview-Commit-ID: AoptjhT1Hln
--HG--
extra : rebase_source : a0870e54038697f08cf14e7babffdb014a7a3c7d
Right now if no minidump file is present in the minidump folder,
the check_for_crashes method returns False. Whereby in all other
cases the number of crashes is returned.
To be consistent this method should always return a number, and
in case of no minidumps it should be 0.
MozReview-Commit-ID: 3DTgxn41TVn
--HG--
extra : rebase_source : 1631313878b596607ede27ebb04f95a64e2f9e2e
Split single unit test module into different modules separated
by area of test coverage.
MozReview-Commit-ID: Blh8V46kDq1
--HG--
extra : rebase_source : 64bfa620286904fdb2bde114efb337d0dd5d42b7
There were two issues:
1) The mach command name in resolve.py was wrong.
2) The marionette harness uses deepcopy on the passed in kwargs and sometimes
the 'log' argument that testing/mach_commands.py was passing in can be a class
instance (which can't be deepcopied).
MozReview-Commit-ID: 5gPxuiHs3dY
--HG--
extra : rebase_source : 63bc9c84fdcb540862f1dcbc2654bf5729e0dec8
Remove RemoteB2GVersion from mozversion and associated parameters from
mozversion.get_version(). Other than the cli interface modified here,
there are no in-tree clients of get_version() using the remote parameters.
This moves the shutdown monitor for the Firefox process from
geckodriver to mozrunner, which is a more suitable home for it.
We will likely need specialised versions of this in the future with
products such as GeckoView and Fennec.
In addition to the move it also cleans up the polling loop by
employing std::time::SystemTime which lets us match on the elapsed
time since its construction. This seems nicer than having to perform
division operations on integers, which in Rust are inherently unsafe
(there is no guard against SIGFPE).
This change should be functionally equivalent to the existing code.
MozReview-Commit-ID: 1asnFbixhcY
--HG--
extra : rebase_source : f21f734862bfbbc1ed665dc9c9f611c5968d662f
This renames RunnerProcess::status() to ::try_wait() for symmetry
with std::process::Child::try_wait() in the standard library.
The patch also makes an attempt at cleaning up its usage in geckodriver,
however this can be further improved.
MozReview-Commit-ID: 14ihT7MpM7l
--HG--
extra : rebase_source : 4e96c79c6ebbb256c4a08cb4dd86c99aacaa13ac
We can pick up std::io::Result and std::io::Error directly from
the std::io namespace without having to rename them.
MozReview-Commit-ID: 9Xz92HvcFpO
--HG--
extra : rebase_source : 89a006c40e11d9e7fc5706d3a6612f916e00f919
This renames RunnerProcess::stop() to ::kill() for symmetry with
the standard library's std::process::Child.
MozReview-Commit-ID: 20vSni9bA0X
--HG--
extra : rebase_source : 112b29249563154b50d9a72c141034e5cdf7f19b
The ideom for getters in Rust is to not prefix them with "is_".
Setters should, however, have the "set_" prefix.
MozReview-Commit-ID: 9kXHBYGK7aL
--HG--
extra : rebase_source : 6c2591771646c8b7c5b0e6b1af5427455938b4cf
Without returncode and wait() being overridden the default
implementation of the Runner class takes precedence and will
run the check for the adb command but not the remote process.
This always returns 0 because adb runs or forks itself as daemon.
Instead the remote process has to be checked for existence.
MozReview-Commit-ID: GvuAaMSxBT2
--HG--
extra : rebase_source : e84b52fdc9ce48617102650d6d0ae73e90899538
The output formatters provided by mozlog are well-documented in the
online help guide, but this information is not available to users in the
CLI. The `add_logging_group` method extends the consuming project's
command-line interface without referencing mozlog itself. This means
consumers may not have a means to discover the additional information,
and even in cases where they can infer this connection, there is no
indication of the stability of the behavior.
Extend the description of the built-in output formatters to explain
their origin and reference the relevant documentation.
--HG--
extra : histedit_source : 9069af86efc67232e059176f99a877c513644ce2
This implements a chunk_by_manifest algorithm. It is similar to chunk_by_slice
in that it tries to make an even number of tests run in each chunk. However,
unlike chunk_by_slice it will guarantee that tests in the same manifest will
all run in the same chunk. This makes it suitable to use with run-by-manifest.
This means the chunks won't be perfect (as manifests are differnet sizes). It
is also prone to more randomization, similar to chunk-by-runtime.
In fact, this algorithm is nearly identical to the chunk-by-runtime one, so it
was refactored out to a base class.
MozReview-Commit-ID: HI2ByxW0i8V
--HG--
extra : rebase_source : e066c034b85222d26bafe6873a80366d5bd9df9e
Pass --appname org.mozilla.geckoview.test to 'mach mochitest' or
'mach reftest'. This runs the tests without e10s currently.
MozReview-Commit-ID: 7TIvA3zRCw2
The output formatters provided by mozlog are well-documented in the
online help guide, but this information is not available to users in the
CLI. The `add_logging_group` method extends the consuming project's
command-line interface without referencing mozlog itself. This means
consumers may not have a means to discover the additional information,
and even in cases where they can infer this connection, there is no
indication of the stability of the behavior.
Extend the description of the built-in output formatters to explain
their origin and reference the relevant documentation.
--HG--
extra : rebase_source : 5e7420f8d1589dccc335b0a48c8967d4928f959f
Since we're adding specific 'task_regexes' for each new suite definition,
this will allow us to schedule tests of these subsuites with
|mach try fuzzy <path>|.
MozReview-Commit-ID: 2mDSneV95lG
--HG--
extra : rebase_source : 467b9d885e92c1c855ed547f2a7496b1062f2dc2
The end goal here is to be able to use |mach try fuzzy <path>| with tests that
belong to a subsuite. To do this, we need a unique 'task_regex' value for each
subsuite so that we can map a test path back to a set of tasks.
This removes the TEST_FLAVORS dict (which was mostly just a redefinition of the
data in TEST_SUITES), and instead provides two new private mappings:
<flavor> -> suite definition
(<flavor>, <subsuite>) -> suite definition
To retrieve a suite definition given a flavor/subsuite, consumers can now call
get_suite_definition.
MozReview-Commit-ID: 2pe1v1IHUVy
--HG--
extra : rebase_source : 6fff947ba214112ccf16c894174a6a0e2487111a
This removes a lot of redundant alias definitions by calling lower() on the
user input. It also adds a couple of new aliases that look like they might
be useful.
MozReview-Commit-ID: 3Aix4LPB8wg
--HG--
extra : rebase_source : c4bdc327bd737a18f03952bb360af35608d091f1
In contrast to Posix the returncodes on Windows have positive
and not negative numbers.
MozReview-Commit-ID: 4foHWf9RR0B
--HG--
extra : rebase_source : 8e06cbb3e669fea7abe46cd8b53386b56030574d
Currently the returncode gets set immediately after the process
has been terminated via TerminateJobObject() or TerminateProcess().
Given that in both cases the process has not been quit yet, but
still waits for all streams to be closed, the returncode has to
be set by via wait().
Also in case of TerminateJobObject() the _cleanup method is never
called if an exception occurs.
MozReview-Commit-ID: 4NEyqafN0DD
--HG--
extra : rebase_source : ae176d5e052785cc77865e1bf220013e87d7a3f0
The psutil package has only been used to check for the existence
of a given pid. Given the troubles with getting psutil compiled
on Windows, or by supplying the correct wheel, it has been decided
to get rid of this dependency.
Instead the ProcessHandler class itself now got the feature to
determine the existence of a pid by using ctypes to do the
necessary Windows API calls.
MozReview-Commit-ID: KAiSv0AH8HZ
--HG--
extra : rebase_source : 55e9ecac6ce12b0abcbaceb9aa385100744b16dd
Upgrading to rust-ini 0.10.2 has the benefit that it no longers
depends on a too specific version of the log crate. We currently
compile two different versions of log as part of the geckodriver
build, and it will marginally increase compile performance not to
compile that twice.
MozReview-Commit-ID: HAwa4Kg8Lyn
--HG--
extra : rebase_source : d81b3450934f011663b508271c8c6a0f92997490
Add ACCESS_COARSE_LOCATION to the Fennec and GeckoView list of
permissions. For completeness, also add ACCESS_COARSE_LOCATION to JS
modules that handle runtime permissions.
MozReview-Commit-ID: 8UHaiJcRnq
--HG--
extra : rebase_source : 5a74d4138d6d7b4bf6cf70724f695ff06201c38c
The third_party/rust/mozprofile has not been deleted because mozrunner
also depends on it. We will have to run "./mach vendor rust" again
once both these changes have landed in order to remove the third-party
dependency from crates.io. This work is tracked in bug 1430158.
MozReview-Commit-ID: 5Q3PdTS03wm
--HG--
extra : rebase_source : a3b52bcb4c2047ddd81b830e4e2f349d8396ee79
This moves the Rust crate mozprofile into central from GitHub.
The old repository will be graveyarded:
https://github.com/jgraham/mozprofile
The git history is not considered important, hence this does not
overlay that onto central like we did for testing/geckodriver and
testing/webdriver.
MozReview-Commit-ID: 5SKlss6uAZ4
--HG--
extra : rebase_source : f19efa20d3eadfbe478b47699512dd22f369dd95
The suite_end action ostensibly supports an extra key, however that extra data never
gets forwarded to the _log_data function.
MozReview-Commit-ID: AfUBmQpx3Zz
--HG--
extra : rebase_source : 5f10746a8384f89ce9fffc28db49b764f6e279ff
Only test_mozprocess.py was still using the C implementation but is
disabled since ages.
Given that the proclaunch script as written in Python replaced the
C implemenation lets remove all the old unused code.
MozReview-Commit-ID: J4izHz5ljtO
--HG--
extra : rebase_source : e33720aa3a6734fa3dd5fc082441ef54d515e75f
The suite_end action ostensibly supports an extra key, however that extra data never
gets forwarded to the _log_data function.
MozReview-Commit-ID: AfUBmQpx3Zz
--HG--
extra : rebase_source : 187fba189deec77b914d455cb55fe21e140bb3c8
We should use posixpath's normpath for calculating the remote
(i.e. device path) with these methods.
MozReview-Commit-ID: zwfsRvCxoe
--HG--
extra : rebase_source : 9635de305db90d0bd99ab080d96d28fcf29cec96
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
This is a major API revision to replace the Python-like API with
something more idiomatically Rust. In particular you now create a
FirefoxRunner object and then call start() and end up with a
FirefoxProcess. This is pretty similar to the Command builder in std.
MozReview-Commit-ID: DmEfIfKSukA
--HG--
extra : rebase_source : 30fba6b2d9584a8a4128b641747beda1d264f7c5
Various updates to emulator command lines. Use -skip-adb-auth. Use -verbose
instead of trying to specify debug categories. Use more -memory and -cores
where applicable. Use -ranchu and -selinux permissive where applicable.
This moves the Rust crate mozrunner into central from GitHub.
The old repository will be graveyarded:
https://github.com/jgraham/rust_mozrunner
The git history is not considered important, hence this does not
overlay that onto central like we did for testing/geckodriver and
testing/webdriver.
MozReview-Commit-ID: J4ZYdow2Lkw
--HG--
extra : rebase_source : 1b499b708105a89a5fa3ae6ecac71c4946e20755
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This enables the syntax like:
./mach try fuzzy dom/indexedDB
This will open up the fzf interface like normal, except only tasks
that have tests under dom/indexedDB will be selectable (and there
will only be one chunk per configuration).
This can be combined with -q/--query like normal:
./mach try fuzzy dom/indexedDB -q "!pgo !cov !asan"
When the tasks get scheduled, only the tests under the specified
path(s) will run within the harness.
MozReview-Commit-ID: IHRXXi5mB4G
--HG--
extra : rebase_source : 8a89f255591e6dfa31b1420196c4698f2015d10c
This moves the Rust crate mozversion into central from GitHub.
The old repository will be graveyarded:
https://github.com/jgraham/mozversion
The git history is not considered important, hence this does not
overlay that onto central like we did for testing/geckodriver and
testing/webdriver.
MozReview-Commit-ID: HeBggGmGsg6
--HG--
extra : rebase_source : 14f6943394bd7b6e8daa7a35b29bc209b7ac9ad4
This removes the subcommands for "./mach geckodriver", reverting
it back to have the meaning of running the geckodriver binary.
The build- and test commands are now integrated with mach, which
means you can run "./mach build testing/geckodriver" and "./mach
test testing/geckodriver" to run tests. This is backed by a new
top-level "./mach geckodriver-test" command, which we will not be
announcing.
MozReview-Commit-ID: CiQsfNqrvIp
--HG--
extra : rebase_source : 6c492b7e1128e4858e42ae4bb35ab4b29564dbeb
This makes several changes to make the 'mach' format cleaner and easier to
read. Some of the changes include:
* No longer print the 'action' no matter what. Printing the action for things
like 'log' or 'process_output' was redundant and caused verbosity. Now this
is done on a case by case basis (things like TEST-START/TEST-END will still
have their actions printed).
* Color coded the process id for 'process_output' actions. This is a dim cyan
to avoid conflicts with other actions.
* No longer quoting 'process_output' messages
* No longer printing thread information. In 99% of the case, this was just
dumping 'MainThread' over and over again. Perhaps printing this could be an
option on the formatter.
* Muted timestamps to help the important parts stand out better
* Colorized suite summary headings
* Unexpected statuses in _format_expected() are always red (never yellow).
This is to help make it stand out from all the other yellow text that gets
printed.
* Internal cleanup/refactoring
MozReview-Commit-ID: LAuYfqYkUPe
--HG--
extra : rebase_source : 6cab1bc3e38838f200f90acc2fff8dcad3d394f3
This makes several changes to make the 'mach' format cleaner and easier to
read. Some of the changes include:
* No longer print the 'action' no matter what. Printing the action for things
like 'log' or 'process_output' was redundant and caused verbosity. Now this
is done on a case by case basis (things like TEST-START/TEST-END will still
have their actions printed).
* Color coded the process id for 'process_output' actions. This is a dim cyan
to avoid conflicts with other actions.
* No longer quoting 'process_output' messages
* No longer printing thread information. In 99% of the case, this was just
dumping 'MainThread' over and over again. Perhaps printing this could be an
option on the formatter.
* Muted timestamps to help the important parts stand out better
* Colorized suite summary headings
* Unexpected statuses in _format_expected() are always red (never yellow).
This is to help make it stand out from all the other yellow text that gets
printed.
* Internal cleanup/refactoring
MozReview-Commit-ID: LAuYfqYkUPe
--HG--
extra : rebase_source : 41aa8651fc8d182bfcbd57c1d97b1bee437d478c
When 'summary_on_shutdown' is True (which is the case for |mach test| and
|mach mochitest|, the tbplformatter will now print an overall summary at
the end of the log run.
MozReview-Commit-ID: 9ieqJRcON8e
--HG--
extra : rebase_source : a27f6230c4d2daaa547e6fede24ba0c9ef55bfc0
When 'summary_on_shutdown' is True (which is the case for |mach test| and |mach
mochitest|), BaseSummaryFormatters will save the summary information until the
'shutdown' action is received at the end of the logger's lifetime.
Summary information will no longer be dumped on 'suite_end'.
MozReview-Commit-ID: HKtVr5PxfOy
--HG--
extra : rebase_source : f350f09111deb510b27a4e55797243dda3160869
The mach formatter gathers result counts and unexpected messages during the run
to be dumped in a summary at the end. This is a pattern we'd like to repeat in
several other formatters as well. Rather than re-implementing, this creates a
handler class that does nothing but store the data. Formatters can then choose
how to format this data and when to print it.
MozReview-Commit-ID: HKtVr5PxfOy
--HG--
extra : rebase_source : 22789db1b2fea1e44f47ef1aa9b22b21a6e8649c
It looks like the main cause of intermittent failures in getDirectory is
that the adb pull command fails because the emulator has hung. For other
commands, we usually handle this by checking the return code and raising
DMError if anything fails. There is mozharness/taskcluster code in
place to automatically retry tasks that throw DMError.
It looks like the main cause of intermittent failures in getDirectory is
that the adb pull command fails because the emulator has hung. For other
commands, we usually handle this by checking the return code and raising
DMError if anything fails. There is mozharness/taskcluster code in
place to automatically retry tasks that throw DMError.
Calling shutdown() causes two things to happen:
1) A 'shutdown' action is implicitly logged so handlers/formatters
can do things on log shutdown.
2) Further attempts to use the logger raises a LoggerShutdownError.
The shutdown() method is also implicitly called when exiting the context
manager.
MozReview-Commit-ID: LLNojVoCBZY
--HG--
extra : rebase_source : db483da27e82971ade4b8e424f14694fabd050f1
Calling shutdown() causes two things to happen:
1) A 'logger_shutdown' action is implicitly logged so handlers/formatters
can do things on log shutdown.
2) Further attempts to use the logger raise a LoggerShutdownError.
The shutdown() method is also implicitly called when the StructuredLogger's
destructor is run, or when exiting a context manager.
MozReview-Commit-ID: LLNojVoCBZY
--HG--
extra : rebase_source : 373b7e70f6a2121d29d7deccfe9bf4cc0f402e3b
This method has not a single caller and as such doesn't seem to
be necessary anymore.
MozReview-Commit-ID: qhNK3EBc6Q
--HG--
extra : rebase_source : 2978829739f0bc465f98b8f6b727c27a03a42b11
Reading the whole zip entry into memory is inefficient and can cause
OOMs if the entry is large enough. Let the ZipFile object choose the
most efficient extraction strategy instead.
The code in |mach test| for test resolving, should get merged with the TestResolver
class in moztest.resolve. This way it can be shared with other modules and we'll
have a single canonical place for all our test resolving logic.
MozReview-Commit-ID: IHRXXi5mB4G
--HG--
extra : rebase_source : 6f96d06412ab8fa152ac5d9bdd15acbcdc9695c4
The TestMetadata and TestResolver classes aren't technically part of the build
system. The only connection is that they consume some build system output.
The next patch in this series is going to be merging in a bunch of other test
resolving logic from other parts of the tree. Moving this out first allows us
to keep that extra logic out of mozbuild.
MozReview-Commit-ID: 1eq4SjFVCyW
--HG--
rename : python/mozbuild/mozbuild/test/test_testing.py => testing/mozbase/moztest/tests/test_resolve.py
extra : rebase_source : 7ff11f9ec455547533082d20cb5371845f7a4f21
Variable appDir was being referenced before assignment. Changed the try-except-finally blocks to handle the error.
MozReview-Commit-ID: AHEeVhmPfQI
--HG--
extra : rebase_source : b0dd78f3895bb34c4e916bc0441dd9ae5e643dfc
Minor note:
reftests should've turned off uploadEnabled in the first place.
reftests should have unified telemetry on. It's the future.
MozReview-Commit-ID: 9spzuUAXwwP
This fixes an exception when a test_status/test_end is logged before a
suite_start. This case should be an error anyway, but might as well fix this to
keep the logs looking clean.
MozReview-Commit-ID: 2TlWlSmczwH
--HG--
extra : rebase_source : c33aed0870d7b7fa51d855383d6336331d4f22fc
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
This includes code for downloading a Firefox binary, downloading + setting up a tests.zip and
running output through mozharness' output parsers. This is all stuff that will also be required
for the reftest selftests.
I couldn't think of a better location to put this stuff, suggestions welcome.
MozReview-Commit-ID: 59TSbsugT5T
--HG--
extra : rebase_source : a328f6bc90e73fe23f9054933cd01a30065419f6