Updated uniffi-bindgen-gecko-js to work with UniFFI 0.25.2:
- Use `config.toml` to list UniFFI sources. This makes it easier to
associate data with them, for example the `crate_name` field that's
now required to generate the sources.
- Enable the `extern-rustbuffer` feature on `uniffi_core`
- Updated the external types fixture to work around
https://github.com/mozilla/uniffi-rs/issues/1872
Ran mach vendor and mach cargo vet to update the Rust crates.
Differential Revision: https://phabricator.services.mozilla.com/D195163
If this is not done, the next person to vendor will also make all of the changes in this commit, which is unnecessary noise.
Differential Revision: https://phabricator.services.mozilla.com/D183450
Updated uniffi-bindgen-gecko-js to work with UniFFI 0.25.2:
- Use `config.toml` to list UniFFI sources. This makes it easier to
associate data with them, for example the `crate_name` field that's
now required to generate the sources.
- Enable the `extern-rustbuffer` feature on `uniffi_core`
- Updated the external types fixture to work around
https://github.com/mozilla/uniffi-rs/issues/1872
Ran mach vendor and mach cargo vet to update the Rust crates.
Differential Revision: https://phabricator.services.mozilla.com/D195163
Also remove dependencies that we don't depend on directly. I assume these were
previously added to get a lockfile of sorts, but maintaining our dependencies'
dependencies manually is an excercise in futility.
Let's forget about locking, and if it becomes a problem implement locking into
mach's sites logic.
Differential Revision: https://phabricator.services.mozilla.com/D195300
Updated uniffi-bindgen-gecko-js to work with UniFFI 0.25.2:
- Use `config.toml` to list UniFFI sources. This makes it easier to
associate data with them, for example the `crate_name` field that's
now required to generate the sources.
- Enable the `extern-rustbuffer` feature on `uniffi_core`
- Updated the external types fixture to work around
https://github.com/mozilla/uniffi-rs/issues/1872
Ran mach vendor and mach cargo vet to update the Rust crates.
Differential Revision: https://phabricator.services.mozilla.com/D195163
If this is not done, the next person to vendor will also make all of the changes in this commit, which is unnecessary noise.
Differential Revision: https://phabricator.services.mozilla.com/D183450
This is the latest version that still support 3.7.x. The 8.x series initially requires 3.8 and later
3.9. We could perhaps update to a 3.8-requiring version since this isn't used anywhere in automation,
but this version is a conservative choice for now.
Differential Revision: https://phabricator.services.mozilla.com/D194052
Add an --expected-failures option to `mach wpt-inerop-score`. This
takes the path to a file which has the format:
\# Mark entire test as expected failure
/test/id.html
\# Mark one subtest as expected failure
/another/test/id.html,subtest name
The output is the actual interop score, plus two extra columns, one
giving the fraction of the score accounted for by expected failures,
and one giving the score after accounting for expected failures.
Differential Revision: https://phabricator.services.mozilla.com/D188729
Add support for submitting stacks of commits to Lando for queueing
on Try, instead of pushing to hg.mozilla.org directly. This patch
implements the Device Code Authorization flow for Auth0, simple changeset
discovery and patch gathering, and submissing to Lando via HTTP POST.
Add a `try.txt` virtualenv site that contains packages from the common
virtualenv as well as the `auth0-python` package for verifying Auth0
JWTs. Use this new virtualenv for `mach try` and related subcommands.
Add a `--push-to-lando` flag that controls whether the push will be made
via the Lando API or using the VCS to hg.mozilla.org directly.
Create a `lando.py` module in the `tryselect` package that handles the
details around submitting to Lando. Authentication is handled by the
Device Code Authorization flow, and the returned access token is saved
to the mozbuild state directory. Auth0 details are added to the `.lando.ini`
file in the repo root, and a `LANDO_TRY_USE_DEV` environment variable can
be set to control submitting to the prod or dev Lando environments.
This module also includes patch stack gathering and discovery via `mozversioncontrol`.
mozversioncontrol's `Repository` subclass is extended with helper functions
to gather patch files from Mercurial and Git. We also add a `try_config_commit`
context manager that creates a temporary commit to hold try syntax commit
messages and/or a `try_task_config.json` file, which is removed from version
control on submission.
The `mach try` cram tests now use a separate virtualenv that must be built
before running, causing unexpected output in the tests. Run `mach try --help`
in the test setup to force the virtualenv to be built before running any
test.
`mach try chooser` would previously install packages for a small web application
from a `requirements.txt` file when run. Install these via the new `try.txt`
site environment instead. The required dependencies are also added to the
`python-test.txt` site since they will cause some tests to fail due to the
missing dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D187641
D180501 made the original change that this patch undoes. An earlier
change in that stack inadvertently silently disabled Telemetry, which
hid this issue.
The problem is that `glean` (which we optionally install in the `mach`
site also needs `jsonschema` (and `jsonschema` depends on `pyrsistent`
and `pkgutil_resolve_name`). Since our vendored version was no longer
specified in the `mach.txt` site, it pulled a different version
(`4.19.1`) from the vendored version (`4.17.3`) which causes issues in
the `wpt` site.
Since glean explicitly needs `jsonschema` it never should have been
taken out of the `mach` site, so this patch corrects that mistake.
Differential Revision: https://phabricator.services.mozilla.com/D189553
Update `aiohttp` to version 3.8.5 and `requests` to version 2.31.0,
and vendor their respective dependencies. Add all the new dependencies
to the various required site virtualenv requirements files.
Differential Revision: https://phabricator.services.mozilla.com/D188904
ManifestParser will read TOML files, if present, when use_toml=True
Added tomlkit as a third_party python package
Added poetry-core and tomlkit to pypi (separately as Bug 1845383, Bug 1844787)
Adds TOML test coverage
Adds tomlkit as a dependency of mozharness (in test_archive.py)
Added tomlkit to virtualenv_modules in testing/mozharness/configs/unittests
Removes dependency on six
testing/tools/mach_test_package_initialize.py
- Corrected SEARCH_PATHS
testing/mozharness/mozharness/mozilla/testing/per_test_base.py
- moved `from manifestparser import TestManifest` into function call
to avoid harness inability to locate the internal artifact
- Removed linter warnings
testing/mozbase/manifestparser/manifestparser/manifestparser.py
- Removed linter warnings
- Updated logger usage pattern
- Simplifed _read logic, refactored get_fp_filename()
- Improve context for `include:` logging message
- Defer `import mozlog` until the point of use
testing/mozbase/manifestparser/manifestparser/toml.py
- Removed linter warnings
- Removed unused logger
- Improved readability of read_toml()
testing/mozbase/manifestparser/manifestparser/ini.py
- Removed linter warnings
- Removed unused logger
testing/mozbase/manifestparser/manifestparser/filters.py
- Removed linter warnings
testing/mozbase/manifestparser/tests/test_chunking.py
- Removed linter warnings
Bumped manifestparser version to 2.2.31
Differential Revision: https://phabricator.services.mozilla.com/D184020
Update:
- Glean to v53.1.0
- UniFFI to v0.24.1
- application-services to a recent nightly that uses the above
versions
- Updated `rusqlite` in toolkit/library/rust/shared/Cargo.toml
- Updated `uniffi-bindgen-gecko-js` to work with the new UniFFI. Also
updated it's askama version.
- Vetted new cargo dependencies
Ran `mach uniffi generate` to regenerate the code.
Differential Revision: https://phabricator.services.mozilla.com/D181872
Now that we selectively load command modules, and activate the command
virtualenv much earlier in the mach process, a lot of the module
dependencies specified in `mach.txt` are no longer necessary there. With
their removal from `mach.txt` they will no longer be automatically
inherited by every site, which reduces potential dependency conflicts
for specific sites.
The `common` site still effectively has the same set of dependencies.
This is the default site that all commands use unless otherwise
specified. Most commands use this site, and going through every command
and seeing if a dependency is or isn't needed, then deciding if or if
not to create a new site for that command made sense was too time
consuming to do here.
Essentially the idea here going forward is that if you're trying to
add/update a new dependency to a command that is currently defaulting to
the `common` site and there is a conflict with one of the dependencies
in `common` you can move your command to a new site specifically for
your command, and you will have the minimal possible set of dependencies
a mach command can have, improving the odds that you can add the
module(s) you need for your command.
Depends on D180500
Differential Revision: https://phabricator.services.mozilla.com/D180501
Update:
- Glean to v53.1.0
- UniFFI to v0.24.1
- application-services to a recent nightly that uses the above
versions
- Updated `rusqlite` in toolkit/library/rust/shared/Cargo.toml
- Updated `uniffi-bindgen-gecko-js` to work with the new UniFFI. Also
updated it's askama version.
- Vetted new cargo dependencies
Ran `mach uniffi generate` to regenerate the code.
Differential Revision: https://phabricator.services.mozilla.com/D181872
Now that we selectively load command modules, and activate the command
virtualenv much earlier in the mach process, a lot of the module
dependencies specified in `mach.txt` are no longer necessary there. With
their removal from `mach.txt` they will no longer be automatically
inherited by every site, which reduces potential dependency conflicts
for specific sites.
The `common` site still effectively has the same set of dependencies.
This is the default site that all commands use unless otherwise
specified. Most commands use this site, and going through every command
and seeing if a dependency is or isn't needed, then deciding if or if
not to create a new site for that command made sense was too time
consuming to do here.
Essentially the idea here going forward is that if you're trying to
add/update a new dependency to a command that is currently defaulting to
the `common` site and there is a conflict with one of the dependencies
in `common` you can move your command to a new site specifically for
your command, and you will have the minimal possible set of dependencies
a mach command can have, improving the odds that you can add the
module(s) you need for your command.
Depends on D180500
Differential Revision: https://phabricator.services.mozilla.com/D180501
Mike Hommey
Noemi Erli
Ben Dean-Kawamura
ahochheiden
Narcis Beleuzu
Andrew Halberstadt
Tom Marble
Cosmin Sabou
James Graham
Alexandra Borovova
Jan-Erik Rediger
Kagami Sascha Rosylight
Cristina Horotan
Butkovits Atila
Julien Cristau
Connor Sheehan
Sandor Molnar
Logan Rosen
Travis Long
Harshit Sohaney
Natalia Csoregi