This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
At the moment, lucetc is not useful by default, only when enabling wasm
sandboxed libraries manually, and in that case, configure knows to
bootstrap lucetc itself. Furthermore, lucetc is set to be replaced with
wasm2c, which is in-tree and doesn't require bootstrapping at all.
Differential Revision: https://phabricator.services.mozilla.com/D120051
The very first time an Android AVD starts it runs some one time jobs to
properly set up the AVD.
To avoid running the setup every time we run tests in automation, we can boot
the AVD before packaging it so that the testing jobs can use a "prewarmed" AVD
instead.
Differential Revision: https://phabricator.services.mozilla.com/D119225
Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
Bug 1719229 broke the install by accident, but configure takes care of
it by default since bug 1716911, bug 1716912 or bug 1717585 depending on
the platform, so we can just stop installing it from mach bootstrap.
Differential Revision: https://phabricator.services.mozilla.com/D119933
Some developers hold onto a `comm` directory as a mount point
that they conditionally populate depending on whether they're working on
Firefox or Thunderbird.
The "`comm` directory exists == is a thunderbird checkout"
assumption isn't compatible with this workflow.
The fix embraced by this patch is to check if the `comm` directory has
any contents.
Differential Revision: https://phabricator.services.mozilla.com/D119193
These are enough for me to run bootstrap+configure+build.
Some touch third-party code (gyp), but per discussion in the earlier
versions of this revision that seems fine.
Differential Revision: https://phabricator.services.mozilla.com/D119080
When running `mach python-test` on a clobbered tree, we create both the
python-test and common virtualenvs, but the former should be enough. The
latter is only created when running tests that use the BaseConfigureTest
class, when it indirectly includes init.configure, which makes the
configure sandbox run the virtualenv_python3 function, which ends up
initializing the common virtualenv. We only don't end up re-executing
that virtualenv python thanks to 6680ca0acc27 which was a workaround
that would allow any virtualenv in $objdir/_virtualenvs, while still
creating a virtualenv it won't use.
Tests now tell virtualenv_python3 to not use the normal virtualenv
manager, and remove the workaround.
Differential Revision: https://phabricator.services.mozilla.com/D118775
These are enough for me to run bootstrap+configure+build.
Some touch third-party code (gyp), but per discussion in the earlier
versions of this revision that seems fine.
Differential Revision: https://phabricator.services.mozilla.com/D119080
When we customized the list of possible `applications` for M1 Macs, the
change was only applying to the displayed list, but not the actual
list that the choice was indexed against.
This is fixed by properly using `applications` instead of
`APPLICATIONS` where relevant.
Note that it's still possible to manually request an
`artifact_mode` if you provide it as an argument for `./mach bootstrap`,
but this workflow is usually only done by devs who are familiar with all
the applications, and therefore likely know what they're doing.
Differential Revision: https://phabricator.services.mozilla.com/D118625
This was added ing bug 1352595. It has only been used briefly, and we
since then have gone all the way to never compress omni.ja. Even if we
did go back to compressing, we'd probably go with zstd rather than
brotli.
The gecko-side support for this has only ever been nightly-only.
Differential Revision: https://phabricator.services.mozilla.com/D118655
`_get_infer_config()` returns 3 items, but the existing code expects 2.
Add a third `_` to capture the other unwanted item.
Differential Revision: https://phabricator.services.mozilla.com/D118535
wireless-tools-devel isn't available on Rocky Linux. Fortunately, it doesn't appear to be needed for the build anymore, and it was added almost a decade ago, so it should be safe to remove.
Differential Revision: https://phabricator.services.mozilla.com/D118532
In the existing behaviour, we would return a node/npm executable from
`find_executable()`, even if we couldn't extract a version from it or if
the extracted version was insufficient.
Now, we fail early if the detected node/npm is insufficient.
Differential Revision: https://phabricator.services.mozilla.com/D118377
As :julienw beautifully described on Bugzilla,
we no longer need to search for "nodejs" since all
packages providing Node >= v12 will provide the `node`
binary.
See his comment here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1716600#c4
Base-toolchain tasks with Node v10 should still be
happy because, unlike Debian's Node v10, they provide
a `node` binary instead of `nodejs`.
Differential Revision: https://phabricator.services.mozilla.com/D118375
(Tl;dr: The original author of this patch was axel@mozilla.com (:pike).
This patch has been modified to run in production automation.)
Cross-channel takes all the en-US strings from the shipping train branches
and consolidates them into a single repository. Originally, this ran out of
https://hg.mozilla.org/users/axel_mozilla.com/cross-channel-experimental/ .
The original version was coupled tightly with specific hg internals, making
hg upgrades fragile. Axel wrote
https://bug1659691.bmoattachments.org/attachment.cgi?id=9170636 before
handing off project ownership; this is the original patch to stop replaying
history to simplify the logic.
This patch also automates the previously manual preparation steps, allows
for running both in automation and locally, and adds retries for production
robustness.
Differential Revision: https://phabricator.services.mozilla.com/D116537
Having separate `<name>.pth` files in the virtual environments
isn't providing an advantage. We can simplify configuration
by putting all `pth` adjustments into a single file: `mach.pth`.
Differential Revision: https://phabricator.services.mozilla.com/D117710
This has two benefits:
1. `handle_package()` becomes more clear - rather than referring to
`action` and `package` with array index numbers, we now give
them real names. The benefit here is also shown in `up_to_date()`.
2. This makes the top-level parser for `packages()` less opinionated
about sub-formats: if an action has a nested structure, it should
have the flexibility to define what it looks like.
Differential Revision: https://phabricator.services.mozilla.com/D117708
After some testing in `try` and locally, the manual
`PYTHONEXECUTABLE` definitions shouldn't be needed
anymore.
There's been some work on Brew's
Python to improve its `sitecustomize` behaviour.
The most likely improvement is:
https://github.com/Homebrew/homebrew-core/pull/65297
However, I'm not fully confident in this change.
If it fails, it's more likely to affect developers
than CI. I think it's worth attempting a landing,
because if the variable is indeed obsolete, then
deleting it will avoid some spicy "action-at-a-
distance" behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D117452
Vendoring wheels has three benefits:
* There's far less files, so Firefox checkouts will be smaller.
* It works around `zipp` not allowing `pip install`
from extracted source `tar.gz` files. Now, we should
be able to use the pip resolver against vendored
packages, which will be needed for future
mach virtualenv work.
* `./mach vendor python` takes far less time to execute.
Since we need the raw Python to be available to add to the `sys.path`,
we extract the wheels before putting them in tree.
Due to the structure of some wheels being less nested
than of a source `tar.gz`, `common_virtualenv_packages`
needed to be adjusted accordingly.
`install_pip_package()` had to be tweaked as well since you can't
`pip install` an extracted wheel. So, we "re-bundle" the wheel
before installing from a vendored package.
Replace python packages with wheels where possible
This contains the vendoring changes caused by the
last patch.
For reviewing, there's a couple things to note:
* A bunch of files are deleted, since there's generally
less files in a wheel than in a source archive.
* There's a new `.dist-info` directory for each
extracted wheel, so expect roughly 5 or
6 new files for each wheel'd package.
* There should be no source code changes other than
moves from package names changing from having
`-` to having `_`.
Differential Revision: https://phabricator.services.mozilla.com/D116512
As pointed out by Harry, this will help in the short-term with
onboarding new developers who will be using M1 macs.
Note that this patch doesn't leverage the "instance" classes to define
whether they're artifact-mode compatible or not, and that's because:
* Most (all except one?) of the systems support artifact mode, therefore
* Since this is a temporary workaround, it's more deletable to have
a top-level `if/else` than to add a `supports_artifact_mode` property
to each Bootstrapper.
Differential Revision: https://phabricator.services.mozilla.com/D117946
Last year, we stopped vendoring Python packages that have native
code. Since we have only had pure-python packages since, the
Windows-specific qualifier (or excluder in the case of `!windows`)
hasn't been needed.
I don't foresee us needing it again, but if anything we can peel it
back from `hg` history if this assumption is incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D117468
On Windows, Python's temporary directories are placed in `%APPDATA%`.
Unfortunately, the failing tests want to assume that some "other"
path (as a subpath of a tempdir) won't be within any
`filter_args()` known top-level paths, which includes the user's home
dir.
The only reason that this assumption has passed in CI so far is due
to Windows case insensitivity: running locally had `~` evaluated
to `c:\Users\...`, while running in CI had it be `c:\users\...`.
Since the tempdir path started with `C:\Users`, `filter_args()`
would `<path omitted>` in CI but would `$HOME/...` locally.
By not basing the `other_path` on `tempdir`, we now consistently get the
same results across platforms.
Differential Revision: https://phabricator.services.mozilla.com/D117698
The `calls` parameter is expected to be an iterable
container of calls, not a singular call.
This was working in `mock-1.0.0` because `calls`
was (confusingly) allowed to be a single item
if `any_order==False`. This behaviour isn't
the same in the standard library.
Differential Revision: https://phabricator.services.mozilla.com/D117074
`./mach vendor python <package>` was already adding its new package
to `requirements.txt`, so we were getting full resolver support, which
is good. However, it caused our `requirements.in` file to start
getting out-of-date, and therefore made it harder to identify the
top-level dependencies.
Arguably, we could have `./mach vendor python <package>` automatically
update `requirements.in`, too, but then we need to solve the edge cases,
such as "What if the package is already in `requirements.in`? What if
that existing item has a different version?"
The hardest part of updating `requirements.in` was finding it, so I've
also modified the `./mach vendor python` help text to make it more
identifiable.
Differential Revision: https://phabricator.services.mozilla.com/D116386
For "c" (i.e., gcc, clang, and clang-cl), this configures the
`-f{debug,macro}-path-prefix` flags. We'd prefer to use
`-ffile-path-prefix`, but it seems that `clang-cl` does not recognize
that flag.
For "rust" (i.e., rustc/cargo), this configures `--remap-path-prefix`.
This is one step toward getting `sccache` hits across source and
object directories.
Differential Revision: https://phabricator.services.mozilla.com/D113065
Based on the docs and the code within `pathlib2`, it seems to focus
only on backporting the main features of `pathlib` to be available for
Python 2. It does _not_ provide features in newer Python versions
of `pathlib` (such as `is_mount`, new in Python 3.7). Therefore, it
doesn't provide anything that the standard library of Python 3.6+
doesn't have.
Differential Revision: https://phabricator.services.mozilla.com/D117071
Make mozperftest work with the new mozproxy command line
Add ability to run proxy on mobile browser
Add ability to use record and playback modes
Add unit tests
Differential Revision: https://phabricator.services.mozilla.com/D115544
Adds a `mach doctor` check to assert Python's locale is not set to
`UTF-8`, an invalid value due to a Python bug in most pre-3.8 versions.
Differential Revision: https://phabricator.services.mozilla.com/D117081
Adds a check that SSH access to hg.mozilla.org is properly configured.
Attempt to run `ssh hg.mozilla.org` which will authorize to hgmo over
SSH via `pash`, without running any commands on the service. In the case
the user has properly configured SSH we will see a success message and
information on the SCM levels granted to the user. If we don't see
a successful connection, parse the output to ensure the user is using
an email address as their username (which is required on hg.mozilla.org).
If the user couldn't connect yet does have an email address as their
username, notify them that they do not have permission to push to hgmo.
Differential Revision: https://phabricator.services.mozilla.com/D117080
This will both:
* Ensure that developers aren't accidentally using Mach with Python 2
in the year 2021.
* Confirm that CI tasks aren't still using Python 2 with Mach.
* Remove support for Python 3.5, which is EOL'd.
Differential Revision: https://phabricator.services.mozilla.com/D116484
Now that we configure pip within mach virtualenvs to turn off
its "outdated" warning, we no longer need to apply the suppression
as a CLI argument.
Differential Revision: https://phabricator.services.mozilla.com/D116891
We don't offer API splits any more, and with the separation of GeckoView with
the rest of the front-end it's increasingly unlikely that we will in the
future.
This change makes it so that the build name doesn't contain the API version so
that we can update it without breaking all the automation that relies on the
build name.
Differential Revision: https://phabricator.services.mozilla.com/D114369
We don't offer API splits any more, and with the separation of GeckoView with
the rest of the front-end it's increasingly unlikely that we will in the
future.
This change makes it so that the build name doesn't contain the API version so
that we can update it without breaking all the automation that relies on the
build name.
Differential Revision: https://phabricator.services.mozilla.com/D114369
Adds test to ensure that we don't modify files that are vendored
with PyPI.
If a modification needs to happen to a vendored library, we should
instead:
* Modify the library upstream and vendor the new version, or
* Remove the library from requirements.in and requirements.txt so that
it's now a "manually-vendored" library. Note that there many be
issues if this occurs to a library depended on by 3rd-party
libraries.
Differential Revision: https://phabricator.services.mozilla.com/D116428
Generating Python lockfiles is system-dependent, and this currently
mostly affects us just on the Python 3.6 <=> 3.7 boundary - 3.6 requires
a few additional packages like `importlib_metadata` and `iso8601`.
If a different Python version is used, the test in CI is guaranteed to
fail. By validating in advance, we help future vendoring developers
by helping them avoid the wait before CI failure and the time it
takes to troubleshoot.
Differential Revision: https://phabricator.services.mozilla.com/D116773
Rewrite `doctor.py` from an object-oriented paradigm to a simpler
function-based architecture. Each check is a function that returns
or yields `DoctorCheck`s. `DoctorCheck`s contain a status that describes
the status of the check (success, warning, fatal error etc), a string
of text with useful information for display to the terminal, and may
optionally attach a callable which can be executed to fix issues found
by the checks.
`mach doctor` is updated to use the new `run_doctor` function instead
of creating a `Doctor` object. The default value of `verbose` in `run_doctor`
is `False`, meaning only issues with the users system are printed to the
screen.
Most of the existing check logic is left intact from the previous
implementation. Checks for `platform` are changed to use the
`sys.platform.startswith` pattern. The latest MozillaBuild version is
pulled by querying the `tip` commit on hg.mozilla.org instead of using
a hard-coded variable.
Differential Revision: https://phabricator.services.mozilla.com/D116539
HEAD is a symbolic ref that points to the default branch of the
repository, it will point to master, main, or anything else that the
repository is using as its default branch.
Differential Revision: https://phabricator.services.mozilla.com/D116678
This will both:
* Ensure that developers aren't accidentally using Mach with Python 2
in the year 2021.
* Confirm that CI tasks aren't still using Python 2 with Mach.
* Remove support for Python 3.5, which is EOL'd.
Differential Revision: https://phabricator.services.mozilla.com/D116484
I chose to do this at the level of the outer Python invocation because:
1. `python -m cProfile ...` handles writing the file and some other
details. It's possible to rebuild the functionality -- the tools
are there -- but the APIs are awkward.
2. this allows to profile `mach` internals, instead of just the
invoked command's implementation.
This uses the return code of the `get_command` subshell to transmit
the single bit of information "is the flag present".
The Python-level argument is required in order to have `--help` know
about the option and to avoid the `mach` shell script having to filter
arguments.
Differential Revision: https://phabricator.services.mozilla.com/D116151
It's not practically make a difference (the flags we end up setting it
to don't do anything when linking all the wasm files into one).
Differential Revision: https://phabricator.services.mozilla.com/D116437
This will both:
* Ensure that developers aren't accidentally using Mach with Python 2
in the year 2021.
* Confirm that CI tasks aren't still using Python 2 with Mach.
* Remove support for Python 3.5, which is EOL'd.
Differential Revision: https://phabricator.services.mozilla.com/D116484
This could be easily generalized to avoid the updating the virtualenv
more generally, but I think this functionality should be in the
`virtualenv_manager` -- something like `install_pip_binary(...)` -- so
I've just done the most impactful example here.
Differential Revision: https://phabricator.services.mozilla.com/D116148
Another step towards avoiding the need for classes in mach commands;
here we are removing constructors either by changing them into helpers
or by simple refactorings.
Differential Revision: https://phabricator.services.mozilla.com/D112434
Now, when running mach commands that invoke `pip`, it will no longer
inform the user that it needs an update.
We reach into `distutils` to determine the "site-packages" directory
pattern, then apply it to our virtualenv.
Differential Revision: https://phabricator.services.mozilla.com/D115940
At least in PyCharm, expanding a `VirtualenvManager` instance means
resolving all the properties and fields of the instance.
However, if that property is doing non-trivial work, the debugger
wouldn't run that subprocess while we're stopped at a breakpoint.
So, the instance would sit there with the "Collecting data..." text.
Differential Revision: https://phabricator.services.mozilla.com/D115935
This was necessary before because we first started the build by invoking
make with client.mk, which would then invoke configure. But that changed
in bug 1671424, and we now never need make before configure has run
(except in tests, for which we implement a fallback).
Differential Revision: https://phabricator.services.mozilla.com/D116064
Another step towards avoiding the need for classes in mach commands;
here we are removing constructors either by changing them into helpers
or by simple refactorings.
Differential Revision: https://phabricator.services.mozilla.com/D112434
A clobber must be able to run, even if `substs` (configure output)
is not available.
However, when this behaviour was implemented, it was set up to replace
all usages.
Since we're trying to make mach commands no longer objects, this
kind of overriding won't be possible in the future. Fortunately, it's
not needed: only `Clobberer` needs a fallible substs, the other
consumers don't!
Differential Revision: https://phabricator.services.mozilla.com/D116128
Back-to-back `./mach clobber gradle` invocations were failing
because `shutil.rmtree(..)` would complain that the target directory
didn't exist.
Differential Revision: https://phabricator.services.mozilla.com/D116129
No longer includes `python` in the `./mach clobber` defaults since
python cache files should no longer be affecting `./mach artifact`.
Removes `third_party/python` purging from `./mach clobber python`
since we don't build native Python modules there.
Moves virtualenv-purging from `./mach clobber objdir` to
`./mach clobber python`.
Differential Revision: https://phabricator.services.mozilla.com/D115728
Accidentally missing a `return` in a code path could mean that
`handle_package(...)` would accidentally do an action _and_
raise the "Unknown action" error.
This change resolves that, and it simplifies the code a bit.
Differential Revision: https://phabricator.services.mozilla.com/D115923
`MACH_VIRTUALENV` was never used, and `MOZBUILD_VIRTUALENV` was never
set (the virtualenv was always activated during the build, rather
than before).
Differential Revision: https://phabricator.services.mozilla.com/D115921
This was originally set up so that tests wouldn't "create a new
`virtualenv` for no reason." However, virtual environments now will have
different packages installed, and therefore the separation is necessary.
So, for the virtual environment used for builds (regular or for tests):
* We want it to be able to reuse the build venv, if it already exists.
* We don't want to pollute a `pytest` virtualenv with build-specific
packages.
Differential Revision: https://phabricator.services.mozilla.com/D115641
We had split up `init` from `init_py3` because `mach` had
traditionally been invoked by either Python 2 or Python 3, and
the two couldn't share the same virtualenv.
Now that the same context isn't shared by both Python 2 and 3
3
(developers always use Python 3, and the remaining Python 2
usages are CI jobs that never reuse the objdir with Python 3),
We can centralize on a single default virtualenv.
I've called this "common" instead of "init" to clarify its
existing position as the virtualenv that's used by many different
commands. As we associate virtualenvs with requirement definitions,
it'll also make the file less confusing: it's a "common" requirement
definition as opposed to an "init" one.
Differential Revision: https://phabricator.services.mozilla.com/D115635
Now, when running mach commands that invoke `pip`, it will no longer
inform the user that it needs an update.
We reach into `distutils` to determine the "site-packages" directory
pattern, then apply it to our virtualenv.
Differential Revision: https://phabricator.services.mozilla.com/D115940
At least in PyCharm, expanding a `VirtualenvManager` instance means
resolving all the properties and fields of the instance.
However, if that property is doing non-trivial work, the debugger
wouldn't run that subprocess while we're stopped at a breakpoint.
So, the instance would sit there with the "Collecting data..." text.
Differential Revision: https://phabricator.services.mozilla.com/D115935
We were raising an exception as a result of a python error
which was masked by a catch statement that thought we didn't
know how to remove the file. But we did.
Fix the python error, and add an exception at the end of the
function to be raised and then caught when we really don't know
how to remove a file.
Differential Revision: https://phabricator.services.mozilla.com/D115936
As a step towards moving mach commands outside of classes, this converts all
properties into methods so that they can later become top-level helper functions.
Differential Revision: https://phabricator.services.mozilla.com/D112196
Instead of using the pushlog, grab the hg log using a revset to avoid
being confused by branches: we're looking for revisions that are
ancestors of the new revision but not of the previous tag, i.e.
"current % previous".
Differential Revision: https://phabricator.services.mozilla.com/D115624
Instead of using the pushlog, grab the hg log using a revset to avoid
being confused by branches: we're looking for revisions that are
ancestors of the new revision but not of the previous tag, i.e.
"current % previous".
Differential Revision: https://phabricator.services.mozilla.com/D115624
Copy / migrate strings from onboarding/defaultBrowserNotification. Add updated ltr/rtl images and show them for pin and pin+default. Dynamically adjust steps and record telemetry to identify what was shown. Handle button actions based on string ids. Alias upgradeDialog to aboutwelcome for now. Avoid oddness with scrollbars by hiding horizontal scroll.
Differential Revision: https://phabricator.services.mozilla.com/D115142
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
Added two fields:
1. Collect if the current shell is opened via vscode.
2. Connect if it's a remote ssh connection n the current shell.
Differential Revision: https://phabricator.services.mozilla.com/D114323
A `.arcconfig` may exist in the `.git` directory. Within worktrees,
the `.git` folder isn't at `<topsrcdir>/.git`, so we have to resolve it.
Differential Revision: https://phabricator.services.mozilla.com/D113320
While here, remove the unused clippyProcess.config. And because we need
to manipulate `$PATH` before running `cargo`, use the same wrapping
function in `get_clippy_version`.
Differential Revision: https://phabricator.services.mozilla.com/D113902
The `target_dir` is always the objdir, since we try to share compile
output. Therefore, storing it in `RustLibrary` shouldn't be necessary.
Removes the associated `RUST_LIBRARY_TARGET_DIR` moz.build option
as well.
Differential Revision: https://phabricator.services.mozilla.com/D113565
Newer versions of Windows don't allow un-elevated processes to access
the list of Windows Defender exclusions.
Rather than incorrectly falling back to assuming that there's no
exclusions, we now instead skip the exclusion check.
Differential Revision: https://phabricator.services.mozilla.com/D112648
Since Python 3, attempting to fetch a registry key that doesn't exist
throws `FileNotFoundError`, not `WindowsError: [Error 2]`.
Differential Revision: https://phabricator.services.mozilla.com/D112647
As a step towards moving mach commands outside of classes, this converts all
properties into methods so that they can later become top-level helper functions.
Differential Revision: https://phabricator.services.mozilla.com/D112196
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
Check if a user is a Mozilla employee by checking their
Bugzilla groups, or checking if their VCS email ends
with "@mozilla.com".
When a user is setting up a new build environment, telemetry
will be automatically enabled for them if they are an
employee. If they're not an employee, they'll be asked
if they want to opt in.
Differential Revision: https://phabricator.services.mozilla.com/D106315
Migrates two strings to fluent and uses sentence casing.
Places identity security block into a toolbar button.
Fixes margin spacing.
Removes green color from secure connection.
Differential Revision: https://phabricator.services.mozilla.com/D111368
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
Migrates two strings to fluent and uses sentence casing.
Places identity security block into a toolbar button.
Fixes margin spacing.
Removes green color from secure connection.
Differential Revision: https://phabricator.services.mozilla.com/D111368
Migrates two strings to fluent and uses sentence casing.
Places identity security block into a toolbar button.
Fixes margin spacing.
Removes green color from secure connection.
Differential Revision: https://phabricator.services.mozilla.com/D111368
I manually compared `$TOPOBJDIR/faster/unified_install_dist_bin` for
an artifact and a non-artifact build, and found only a few
pre-processing differences. I can't recall why this wasn't supported
initially; I think it used to be that manifests overlapped and that
the interaction with the RecursiveMake backend was more complicated.
But I see no reason why this shouldn't work, and would like to get
some folks to test it in the wild.
Differential Revision: https://phabricator.services.mozilla.com/D110311
***
Bug 1698838 - Restrict the list of linters to valid formatters r=ahal
***
Bug 1698838 - Abort formatting even if one of the linters passed is invalid r=ahal
***
***
Differential Revision: https://phabricator.services.mozilla.com/D109231
This also makes `MOZ_UPDATE_AGENT` depend on `MOZ_BACKGROUNDTASKS`.
There's no need to lint the `tools/update-programs` project, since
it's not a supported configuration. The next consumer can
rehabilitate it or remove it.
Differential Revision: https://phabricator.services.mozilla.com/D111313
Due to strange module-name generation we do (e.g.:
`mach.commands.be68b9824a51408e815262b2e8f21d6b`), Sentry's conversion
of absolute paths to local paths fails - instead, the path remains
absolute, but without the leading forward slash. (Except on Windows,
where `c:/` is maintained).
We resolve this by not requiring the leading slash when patching
absolute paths.
Differential Revision: https://phabricator.services.mozilla.com/D110436
This can occur if the user is using cinnabar and it fails to find the
equivalent hg revision for their current base commit.
It's significantly less valuable to have exceptions with an "anonymous
release", so we skip these exceptions instead.
Differential Revision: https://phabricator.services.mozilla.com/D110481
To track whether issues being reported are for old versions, we attach
an hg revision hash as a release version with each report.
We use the base_ref because:
* It's a public revision that we can look up, and
* Since we only submit Sentry events when mach is unmodified,
it's essentially acting as a version identifier.
Differential Revision: https://phabricator.services.mozilla.com/D108307
AFAIK, while mochitests have resource-usage.json data with the same
format as build_resources.json, there isn't much of anything to display
that data in a human-friendly manner. As a helper of sort for all the
tasks that already expose their json data without a nice way to display
it, allow the build resources usage report UI that `mach resource-usage`
displays (or build_resources.html on build tasks on treeherder), to load
arbitrary json files if their url is dropped on the page (from e.g.
drag-and-dropping the link to the file from treeherder).
Differential Revision: https://phabricator.services.mozilla.com/D109030
This commit adds a simple pageload test, a warm pageload of https://www.google.com.
Low-level perfstats are collected.
All platforms were included. Not running as a cron job.
The motivation is that we can now collect low-level perfStats timings and determine how useful they will be for performance work.
Differential Revision: https://phabricator.services.mozilla.com/D109072
This commit adds the core algorithm for editing moz.build files, tests for a few
pieces of it, and the code to manually run the algorithm over the gecko codebase
and see dynamically how well it performs at trying to assigning existing source
files back into their original locations.
Differential Revision: https://phabricator.services.mozilla.com/D104754
During `mach bootstrap` for Firefox desktop, m4 is installed via `libgtk2.0-dev`.
Since we don't install that package for Android bootstrap, this causes
configure failures.
Install `m4` as a common package to fix configure on Android. Since we plan
to remove `libgtk2.0-dev` soon, this will also avoid breakage when that change
lands.
Differential Revision: https://phabricator.services.mozilla.com/D108692
The build always uses them anyways, but configure tests don't, and some
of them fail as a consequence in some cases (example: when UBsan is
enabled, all AC_LANG_CPLUSPLUS + AC_CHECK_FUNCS tests fail). We also had
similar problems in the past, such as bug 1513605.
By adding the PIC flags to CFLAGS and CXXFLAGS, we ensure old-configure
tests use the flags as well.
While here, we also remove DSO_CFLAGS, which was always empty, and we
stop passing -fPIC to wasm compiles, because it has no effect there.
Differential Revision: https://phabricator.services.mozilla.com/D108560
The build always uses them anyways, but configure tests don't, and some
of them fail as a consequence in some cases (example: when UBsan is
enabled, all AC_LANG_CPLUSPLUS + AC_CHECK_FUNCS tests fail). We also had
similar problems in the past, such as bug 1513605.
By adding the PIC flags to CFLAGS and CXXFLAGS, we ensure old-configure
tests use the flags as well.
While here, we also remove DSO_CFLAGS, which was always empty, and we
stop passing -fPIC to wasm compiles, because it has no effect there.
Differential Revision: https://phabricator.services.mozilla.com/D108560
When Sentry slurps context, it doesn't normalize os path separators for
us. So, we adapt our path aliasing to always catch both forward slashes
and backslashes.
Removed the `needle is None` guard because it because obsolete after
1695366, which removed the case where `topsrcdir` was `None`.
Differential Revision: https://phabricator.services.mozilla.com/D108667
If the "mach" file and all "*.py" files are unchanged, then the reported
exception is likely legitimate and can be reproduced on the public tree.
Differential Revision: https://phabricator.services.mozilla.com/D108262
This patch:
-Maintains consistency between the fxa and remote tabs' panels "sync now" buttons
-Removes a fluent string no longer in use
-Restores tooltip functionality
Differential Revision: https://phabricator.services.mozilla.com/D106651
Bootstrap runs mach create-mach-environment, which may or may not
successfully install glean. When it doesn't, it's not useful to ask
whether to enable telemetry when it's not going to work.
Differential Revision: https://phabricator.services.mozilla.com/D108131
Updates `./mach bootstrap` to use `--no-interactive` from global args.
Ensures all bootstrap prompts have a default option.
Differential Revision: https://phabricator.services.mozilla.com/D106814
The retry limit doesn't add much value - if user doesn't want
to answer a prompt, they can CTRL-C.
Additionally, `prompt_yesno` doesn't have a retry limit, so
this increases prompt behaviour consistency.
Differential Revision: https://phabricator.services.mozilla.com/D107122