This patch adds a new tool that runs a comparison between two, or more revisions to detect performance changes. Some changes are made to accommodate this new tool alongside the side-by-side tool. The tests for the detector coding are found in another patch in the series. A mozperftest-tools update to 0.2.5 is required for this change.
There is also a CI task that is added in this patch. It's setup in the mach try perf patch in this series, which also has more information.
Differential Revision: https://phabricator.services.mozilla.com/D172282
The previous way of setting textContent via string from the
browser.properties file does not work with the moz-support-link widget
since it has a Fluent ID by default. Instead we migrate the existing
string from the browser.properties file to the browser.ftl file.
Differential Revision: https://phabricator.services.mozilla.com/D170255
This patch allows mobile developers to upload custom APKs for testing through a commit. This allows them to run our performance tests by building locally, and then uploading to CI to run tests there.
The `./mach try perf` command is modified to make this simpler. It accepts either an environment variable, or a path to an APK, and copies it in-tree. After adding it to hg, the command stops running and asks the user to commit the changes. From there the user re-runs the `./mach try perf` command to select the appropriate tests.
Using --browsertime-upload-apk, users can use a custom APK for browsertime tests, and using --mozperftest-upload-apk, users can use a custom APK in mozperftest tests. The reason it's done this way is that we don't have common areas between the two frameworks. The methods are the same in both cases, i.e. for a fenix test, a fenix APK needs to be uploaded.
Differential Revision: https://phabricator.services.mozilla.com/D172435
This patch allows mobile developers to upload custom APKs for testing through a commit. This allows them to run our performance tests by building locally, and then uploading to CI to run tests there.
The `./mach try perf` command is modified to make this simpler. It accepts either an environment variable, or a path to an APK, and copies it in-tree. After adding it to hg, the command stops running and asks the user to commit the changes. From there the user re-runs the `./mach try perf` command to select the appropriate tests.
Using --browsertime-upload-apk, users can use a custom APK for browsertime tests, and using --mozperftest-upload-apk, users can use a custom APK in mozperftest tests. The reason it's done this way is that we don't have common areas between the two frameworks. The methods are the same in both cases, i.e. for a fenix test, a fenix APK needs to be uploaded.
Differential Revision: https://phabricator.services.mozilla.com/D172435
When there is no configured environment, mach cargo commands always need
one. `BuildDriver.build` does create one, but for commands that don't
need that, we do need configure. Ideally, we wouldn't, but that requires
moving all the cargo invocation logic out of rust.mk, which would be
more work.
Differential Revision: https://phabricator.services.mozilla.com/D173109
Since we added a root `pyproject.toml` file, it triggered a code path in pytest
which tries to open the file to read configuration with `tomli`. For whatever
reason, this isn't vendored for wpt and we therefore get import errors.
Differential Revision: https://phabricator.services.mozilla.com/D173166
This patch adds the ability to run manual logins for our websites since it can be simpler, and quicker in some cases. At the same time, a bug with the options handling is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D164590
This results in some changes from our current `isort` configuration. I'm
unclear if it's because ruff isn't at 100% parity with isort, they choose
different defaults or if I missed some configuration.
Either way, the changes all look reasonable to me (see child commit), so I'm
inclined to just accept the new import format it imposes.
Differential Revision: https://phabricator.services.mozilla.com/D172348
Ruff is a very fast linter implemented in Rust and it can act as a drop-in
replacement for flake8. When running the same set of rules across all files
in mozilla-central (without mozlint), flake8 takes 900 seconds whereas ruff
takes 0.9 seconds.
Ruff also implements rules from other popular Python linters such as pylint,
isort and pyupgrade. There are even plans to implement feature parity with
black in the future. Ultimately, it can become our one stop shop for all Python
linting and formatting.
This stack will swap out all our Python lint tools for ruff (excluding black
for now).
Differential Revision: https://phabricator.services.mozilla.com/D172313
Since webrender was enabled by default this was causing pushes with
webrender-only changes to wrongly optimize out most tests.
Differential Revision: https://phabricator.services.mozilla.com/D172778
This results in some changes from our current `isort` configuration. I'm
unclear if it's because ruff isn't at 100% parity with isort, they choose
different defaults or if I missed some configuration.
Either way, the changes all look reasonable to me (see child commit), so I'm
inclined to just accept the new import format it imposes.
Differential Revision: https://phabricator.services.mozilla.com/D172348
Ruff is a very fast linter implemented in Rust and it can act as a drop-in
replacement for flake8. When running the same set of rules across all files
in mozilla-central (without mozlint), flake8 takes 900 seconds whereas ruff
takes 0.9 seconds.
Ruff also implements rules from other popular Python linters such as pylint,
isort and pyupgrade. There are even plans to implement feature parity with
black in the future. Ultimately, it can become our one stop shop for all Python
linting and formatting.
This stack will swap out all our Python lint tools for ruff (excluding black
for now).
Differential Revision: https://phabricator.services.mozilla.com/D172313
We are using features from modern JSONSchema drafts, like dependantRequired, in
the Firefox Messaging System schemas. jsonschema 3.x does not support these
features. Experimenter is also being updated to 4.17.3 and we want to keep our
validation tests in sync with Experimenter.
Differential Revision: https://phabricator.services.mozilla.com/D172457
We are using features from modern JSONSchema drafts, like dependantRequired, in
the Firefox Messaging System schemas. jsonschema 3.x does not support these
features. Experimenter is also being updated to 4.17.3 and we want to keep our
validation tests in sync with Experimenter.
Differential Revision: https://phabricator.services.mozilla.com/D172457
We are using features from modern JSONSchema drafts, like dependantRequired, in
the Firefox Messaging System schemas. jsonschema 3.x does not support these
features. Experimenter is also being updated to 4.17.3 and we want to keep our
validation tests in sync with Experimenter.
Differential Revision: https://phabricator.services.mozilla.com/D172457
For a few NDK releases now, the situation has been simplified wrt
headers and libraries, and while we're currently still using things here
and there because we never changed our ways, we can simplify things a
lot by using the new simplified things. This involves:
- Using a --target that contains the Android version, making clang set
__ANDROID_API__ itself, and makes it look in $sysroot/usr/lib/$target/$ver
when linking.
- Using the sysroot that is under toolchains/llvm/prebuilt/*.
- Removing the hacks around libstdc++/libc++.
This ends up emptying stlport compiler flags, which allows to remove a
bunch of things.
Differential Revision: https://phabricator.services.mozilla.com/D172039
ogiorgis
Matthew Gregan
Greg Mierzwinski
Arthur Carcano
Mike Hommey
Tim Giles
Stanca Serban
Jari Jalkanen
Johan Lorenzo
Iulian Moraru
Malte Jürgens
Alex Hochheiden
Andrew Halberstadt
serge-sans-paille
Kershaw Chang
pmcmanis
Julien Cristau
Cristian Tuns
Barret Rennie
Maxim Cournoyer
Marian-Vasile Laza