Some hooks modules use global variables to share state between hooks calls.
This patch makes sure we reuse the same module instance once it's loaded by a
Hook class.
Differential Revision: https://phabricator.services.mozilla.com/D91096
The supported way of submitting Firefox patches is via moz-phab, so
install it automatically in bootstrap rather than redirecting to docs.
Depends on D90455
Differential Revision: https://phabricator.services.mozilla.com/D90459
Windows handles files in a case-insensitive way. So, when checking if a
file matches a certain extension, that check needs to be
case-insensitive as well.
Differential Revision: https://phabricator.services.mozilla.com/D91057
In the build process, there's two ways that java is used:
* From the path
* From the java-bin-path specified in the mozconfig
Before, to assert that both "java" usages would be consistent, the
implementation assumed that there was only a single "java" binary
per-JDK-version, and all duplicate "binaries" were symlinks to the
original.
However, in Fedora, it has two identical full binaries: one in
$JDK/bin, and one in $JDK/jre/bin. The symlink theory was incorrect.
So instead, we can assert that both "java" usages are consistent
by checking their versions and asserting that they are equivalent.
Differential Revision: https://phabricator.services.mozilla.com/D90918
In the build process, there's two ways that java is used:
* From the path
* From the java-bin-path specified in the mozconfig
Before, to assert that both "java" usages would be consistent, the
implementation assumed that there was only a single "java" binary
per-JDK-version, and all duplicate "binaries" were symlinks to the
original.
However, in Fedora, it has two identical full binaries: one in
$JDK/bin, and one in $JDK/jre/bin. The symlink theory was incorrect.
So instead, we can assert that both "java" usages are consistent
by checking their versions and asserting that they are equivalent.
Differential Revision: https://phabricator.services.mozilla.com/D90774
I randomly noticed in a log file that we don't apply the flags to wasm compilations. I don't have a super strong motivation for this, but eh, we might as well.
Differential Revision: https://phabricator.services.mozilla.com/D90741
If you set a `DEFAULT` `requirements` file in a Python test manifest, the current implementation of `python-test` will try (and usually fail) to install the file once for every test file in parallel. Instead, initializing the environment should be done once when the command starts up.
Differential Revision: https://phabricator.services.mozilla.com/D90475
The manifest file hasn't actually done anything since XPT definitions were
moved to the libxul binary, and now just generates warnings in local builes.
Differential Revision: https://phabricator.services.mozilla.com/D89197
The manifest file hasn't actually done anything since XPT definitions were
moved to the libxul binary, and now just generates warnings in local builes.
Differential Revision: https://phabricator.services.mozilla.com/D89197
I think they're remnants from the past that we don't really need anymore.
And they're making things more complicated for some pending work of mine.
Differential Revision: https://phabricator.services.mozilla.com/D89687
Allows mach commands to define their own glean metrics with the `metrics_path` @CommandProvider parameter.
When `metrics_path` is defined:
* A `metrics` kwarg is provided to the decorated class. This `metrics` handle is a Glean instance, so Glean documentation should be consulted for usage information.
* When `mach doc telemetry` is run, metrics docs will be generated from all the registered metrics files.
Note: there was some consideration between making `metrics_path` a @CommandProvider or @Command parameter.
In the end, @CommandProvider seemed like a better fit because:
* Metrics seem to be more associated with the entire class than a specific command/method. This is because a class represents a "domain", and that domain may have different commands that have overlapping metrics. Accordingly, all the metrics should be defined once as available to the entire class.
* Currently, @Command methods only take parameters that map one-to-one with CLI arguments. It could seem inconsistent to have one exception: the metrics handle
Differential Revision: https://phabricator.services.mozilla.com/D85953
In the patch for bug 1656993, the case in which
get_command was being set was removed.
Accordingly, its usage in CommandAction will always be evaluated to
`False`, and it can be deleted.
Differential Revision: https://phabricator.services.mozilla.com/D90198
When multiple java versions are in use, some OSes have a mechanism to
change the "default"/system Java.
This can cause unexpected build failures if the system Java changes.
So, in bootstrap, if the Java version found is valid, then its path
should be encoded into mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D90163
This was originally meant to allow `virtualenv`s to use packages from a parent Python environment without having to re-install them. This turned out to not pan out as we would have liked, so we're going another way to solve the same problem. Bug 1660351 walked back a bunch of this logic; this patch deletes the rest of it.
Differential Revision: https://phabricator.services.mozilla.com/D89492
I think they're remnants from the past that we don't really need anymore.
And they're making things more complicated for some pending work of mine.
Differential Revision: https://phabricator.services.mozilla.com/D89687
The idea here was that we keep the NDK's downloaded in this directory as a "cache", such that if the download gets interrupted, then we can resume the download from an earlier point. This logic was walked back by bug 1637379, which deletes the cache.
In the spirit of the original version of the code, remove the `os.rmdir()` that was introduced by that bug.
An alternative fix for this is to download the NDK to a temporary directory and just clean that up entirely after every call to `mach bootstrap`, but then we would be forgoing the build cache behavior, which I'm not sure makes sense at this point in time.
Differential Revision: https://phabricator.services.mozilla.com/D90125
VSCode doesn't install by default it's command line integration toolset on MacOS
so w don't have a link to `/usr/local/bin/code` instead we must use the binary from the
`Applications` folder.
Also extens this to other platforms even though it's improbable that we are going to use it
there.
Differential Revision: https://phabricator.services.mozilla.com/D90088
In bootstrap, pacman should ensure its database is up-to-date.
Otherwise, when installing packages, pacman will slowly query every
mirror when attempting to download an out-of-date package.
Differential Revision: https://phabricator.services.mozilla.com/D89958
In addition to the existing build telemetry, also gather the stats and
report with Glean. This new telemetry is reported in tandem with the existing
telemetry to allow testing and confidence before a full roll-out.
Additionally, Glean isn't compatible with Python 2, so the new telemetry only runs
on Python 3 mach commands.
Differential Revision: https://phabricator.services.mozilla.com/D83572
Ted Campbell
Gregory Mierzwinski
Tarek Ziadé
Botond Ballo
Harnaman Kaur
Mitchell Hentges
Andi-Bogdan Postelnicu
Dorel Luca
David Major
Sylvestre Ledru
Ricky Stewart
Kris Maglione
Mike Hommey
Razvan Maries
Tom Ritter
Alexis Beingessner
Andi-Bogdan Postelnicu
Mark Banner
Gijs Kruitbosch
Narcis Beleuzu
Mihai Alexandru Michis
Csoregi Natalia