There's a Windows Defender CLI (`Get-MpComputerStatus`) available, but MozillaBuild
can't (easily) access PowerShell. So, instead, we find Windows Defender status and path exclusions
by checking the registry at HKLM\SOFTWARE\Microsoft\Windows Defender.
Determining if Windows Defender is "on" or not is a surprisingly vague task.
Not only does it encompass a lot of components (of which Ricky and I believe "Real-time protection"
is the part slowing down the build), but there's (at least?) two different kinds of "disabled"
states that it can be in:
* If "disabled" via Settings, it will turn itself back on after a reboot
* If an antivirus is installed, it will turn itself off permanently
Unfortunately, disabling "Real-time protection" in Settings doesn't affect any registry keys, but
I'm opting to ignore this because I doubt many users are manually disabling this protection before
each build. The repercussion of this is that users may be incorrectly warned "your Firefox
directory isn't excluded from Windows Defender!".
Focusing on the antivirus use case and querying the registry I found that:
* Querying the `IsServiceRunning` value wasn't sufficient because new Windows installations didn't have that key
* Querying the `DisableRealtimeMonitoring` value was inconsistent - it can be missing, and not always because an antivirus removed it
* Querying the `DisableAntiVirus` value doesn't _sound_ accurate (we care about Real-time Protection), but it's consistently "off" for non-AV machines, and "on" for machines with an AV installed. So, this is our winner!
TL;DR: there may be some "false positive" warnings about excluding the Firefox srcdir, but they're
accurate for my test cases and workaround-able (just add the exclusion to Windows Defender).
Also, this patch updates our Windows Defender docs to make them:
* More easily link-able
* Have direct advice to resolve the issue
Differential Revision: https://phabricator.services.mozilla.com/D85952
Today we don't require that `mach` `CommandProvider`s subclass from any particular parent class and we're very lax about the requirements they must meet. While that's convenient in certain circumstances, it has some unfortunate implications for feature development.
Today the only requirements that we have for `CommandProvider`s are that they have an `__init__()` method that takes either 1 or 2 arguments, the second of which must be called `context` and is populated with the `mach` `CommandContext`. Again, while this flexibility is occasionally convenient, it is limiting. As we add features to `mach`, having a better idea what the shape of our `CommandProvider`s are and how we can instantiate them and use them is increasingly important, and this gives us additional control when having `mach` configure `CommandProvider`s based on data that is only available at the `mach` level. In particular, we plan to leverage this in bugs 985141 and 1654074.
Here we add validation to the `CommandProvider` decorator to ensure all classes inherit from `MachCommandBase`, update all `CommandProvider`s in-tree to inherit from `MachCommandBase`, and update source and test code accordingly.
Follow-up work: we now require (de facto) that the `context` be populated with a `topdir` attribute by the `populate_context_handler` function, since instantiating the `MachCommandBase` requires a `topdir` be provided. This is fine for now in the interest of keeping this patch reasonably sized, but some additional refactoring could make this cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D86255
A newer version of Glean is needed to take advantage of the recent "optional version" change.
Pins glean to 31.5.0 to avoid breaking changes, such as to the YAML schema.
Differential Revision: https://phabricator.services.mozilla.com/D84566
Check whether Python 3 is up-to-date and bail out with specific installation guidance if not. Don't install or upgrade Python 2/3. Also check whether Python 2 is up-to-date, and while we don't block `bootstrap` on it (because Python 2 isn't required to build), also supplement with specific installation guidance for people who need it.
Differential Revision: https://phabricator.services.mozilla.com/D82739
Also delete a bunch of dead code that was apparently meant to be useful for subclassing, but there's no subclasses of `DebianBootstrapper` in tree.
Differential Revision: https://phabricator.services.mozilla.com/D82073
Installs glean to the currently-active python installation during bootstrap, whether
that be a virtualenv or the system instance of python.
Differential Revision: https://phabricator.services.mozilla.com/D83012
If we're going to ditch the old breakpad dump-syms from the build, people
are going to need have this locally if they ever want to build packages,
etc.
Differential Revision: https://phabricator.services.mozilla.com/D83150
If we're going to ditch the old breakpad dump-syms from the build, people
are going to need have this locally if they ever want to build packages,
etc.
Differential Revision: https://phabricator.services.mozilla.com/D83150
This is where the `compare-mozconfig` test properly belongs, and `mozbuild` tests already re-run every time a `mozboot` file changes.
Differential Revision: https://phabricator.services.mozilla.com/D83130
Since bug 1647865, we're no longer allowing `bootstrap` to be run with Python 2. Therefore we have leeway to make a bunch of simplifications.
Differential Revision: https://phabricator.services.mozilla.com/D82737
Prior to this patch JAVA_HOME was appended to path and then the first instance
of java on those paths was used and checked for version compatibility. This
meant that if an incompatible version on java is on the path JAVA_HOME could not
be used to point to a different, compatible version.
Following this patch, JAVA_HOME can be used as a more fine grained selector of
java. Only if JAVA_HOME is not set will we check the path. To be clear, even if
JAVA_HOME is set incorrectly, we will not fall back to path -- only if JAVA_HOME
is not set will we try and use the path.
Differential Revision: https://phabricator.services.mozilla.com/D82418
D79393 introduced a new parameter to `configure_git()` but there is a remaining call that does not pass it. This patch fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D82129
When moving from mozreview to Phabricator, the old mozreview git hook
had to be removed. Logic to automate the removal of this hook was added
to vcs-setup.
This commit removes this automated removal since it has been 2 years
since it landed.
Differential Revision: https://phabricator.services.mozilla.com/D82125
We get a lot of bugs about building Firefox for Android not working, and there's been ongoing confusion about whether this is something that does work or who has ever worked. The warning should hopefully clarify the current situation for people.
Differential Revision: https://phabricator.services.mozilla.com/D81585
This message dates from bug 1177128, the commit where this bootstrapper was added. At the time of writing that was certainly true, but today it doesn't appear to be true in any meaningful way. There's certainly an expectation that installing MozillaBuild and running `mach bootstrap` will get your machine ready to build Firefox; or at least, if it doesn't, it prints out some error messages telling you to do extra stuff, like we see in bug 1644794 for example. Therefore, I don't see how this message is relevant at all any more.
Differential Revision: https://phabricator.services.mozilla.com/D80730
This uses sys.exit() instead of throwing an exception since:
1. It isn't an error, and bug 1646406 isn't finished yet
2. The output is more straightforward for the user
This verification happens separately from the other python-verification logic, but that's
because I wanted the validation to happen as soon as possible - before the user invests too
much time, and before too much of the script ran with the wrong interpreter.
Differential Revision: https://phabricator.services.mozilla.com/D80726
Additionally, recommends the installation of AdoptOpenJDK instead of the Oracle JDK.
This required a different "JAVA_HOME" detection mechanism, which is implemented in this revision.
Differential Revision: https://phabricator.services.mozilla.com/D79547
Previously, python import syntax was used to refer users to the definition of the --application-choice arguments.
However, it isn't straightforward to the uninitiated, especially since it doesn't work in searchfox.
Instead, by providing a file reference, it should be more accessible.
Differential Revision: https://phabricator.services.mozilla.com/D79003
Rather than always printing instructions at the end of the bootstrap phase, we will now create a mozconfig
file if one doesn't exist and there's configuration to be written.
Differential Revision: https://phabricator.services.mozilla.com/D78417
Toolchains that are used for local development need to be built on a level-3
branch to installable via `mach bootstrap`. Add an attribute to track the fact
that a toolchain is used that way, and:
- ensure that everything installed via `mach boostrap` has that attribute set
- ensure that everything with that attribute set is built on trunk projects
We could additionally verify that attribute is only set on things used by
bootstrap, but bootstrap doesn't currently have an exhaustive list of things
that it might install, making that difficult.
Differential Revision: https://phabricator.services.mozilla.com/D77706
This is ugly and complicates the code some but it's manageable and allows us to keep things afloat on macOS while the testing team plugs along with the `mach` migration.
Differential Revision: https://phabricator.services.mozilla.com/D76386
This change doesn't fix all of the boilerplate involved in declaring
that certain packages should be fetched from taskcluster, but it's a
start, at least.
Differential Revision: https://phabricator.services.mozilla.com/D75330
In Bug1127565 bootstrap was given support for the openSUSE Linux distribution
Fetching the Stackwalk toolchain was not added unfortunately
his bug1636797 was hit during testing...
(also fixed some formatting "issues")
Differential Revision: https://phabricator.services.mozilla.com/D75189
This patch is adding an option to push a perftest run in the CI.
It's based on :
- sparse profiles
- push_to_try
- options passed through try_task_config.json
Differential Revision: https://phabricator.services.mozilla.com/D74115
|./mach try| subcommands are now compatible with both python 2 and 3.
Hand-tested with many combinations of subcommand and subcommand flags.
Updates tryselect unit tests to use Python 3.
Differential Revision: https://phabricator.services.mozilla.com/D73398
Install minidump_stackwalk as part of 'mach bootstrap' so that it is readily available
for generating crash reports, if desired.
Differential Revision: https://phabricator.services.mozilla.com/D74442
Mitchell Hentges
Ricky Stewart
Nathan Froyd
Cosmin Sabou
Sebastian Hengst
Bryce
Kagami Sascha Rosylight
Karl Dubost
David Major
Valentin Gosu
Tom Prince
Emily McDonough
Chris AtLee
Cameron McCormack
Alex Vincent
Corentin Arnould
Nicklas Boman
Tarek Ziadé
Geoff Brown