If we are dealing with a markdown file with a front matter,
we read the information from the front matter/YAML,
write a new md file with the right information
and copy it in the target directory
Depends on D54426
Differential Revision: https://phabricator.services.mozilla.com/D54427
--HG--
extra : moz-landing-system : lando
The `onEngagement` task fails on beta due to how the mock extension is created with `useAddonManager: "temporary"`, which prevents the extension from being able to use `browser.urlbar`. That's the only task in the file that does that. I think I copied it from another test file. Not sure why I just didn't use the pattern in this file.
This also removes `incognitoOverride: "spanning"`. It's not necessary and none of the other tasks do that either.
Differential Revision: https://phabricator.services.mozilla.com/D54795
--HG--
extra : moz-landing-system : lando
People do like to use zoom along with transforms for legit reasons, which means
that we get this wrong.
This is unfortunate, as the whole point of the hack was fixing sites that only
used zoom without regressing sites that would do:
zoom: 0.5;
-moz-transform: scale(0.5);
transform-origin: 0 0;
So we're a bit stuck here. The only way to deal with the known regressions is
parsing `zoom: 1` as invalid, which is insane, and it would probably cause other
compat issues... For now disable the pref.
Differential Revision: https://phabricator.services.mozilla.com/D54685
--HG--
extra : moz-landing-system : lando
Our detour cannot handle assembly patterns which is injected by the code coverage
instrumentation. We need to skip them in CCov build.
Differential Revision: https://phabricator.services.mozilla.com/D54745
--HG--
extra : moz-landing-system : lando
Bulk memory reduces active segments to sequences of *.init that are executed
before the start function is called. This implies that an error here is to be
reported as a RuntimeError, as an error in the start function would. The latest
spec tests for bulk-memory check this, so we're required to update as well.
Differential Revision: https://phabricator.services.mozilla.com/D54598
--HG--
extra : moz-landing-system : lando
When fuzzing, return an error instead of crashing in PrincipalInfoToPrincipal() for some error cases.
Differential Revision: https://phabricator.services.mozilla.com/D54215
--HG--
extra : moz-landing-system : lando
Whereas:
- desktop tests don't make this check;
- the check for directory existence has been troublesome and almost never useful;
- bug classification of this condition has been troublesome;
- if a startup crash actually did occur before crashreporter init, there would still be an indication in logcat and possibly a tombstone, and the "No test summary found" check would definitely be triggered;
Let's stop checking for minidumps directory creation.
Differential Revision: https://phabricator.services.mozilla.com/D54755
--HG--
extra : moz-landing-system : lando
Make the $PYTHON3 build var point to a full virtualenv bootstrapped with
the same libraries as the $PYTHON Python 2 build var. This allows us to
upgrade build tasks from $PYTHON to $PYTHON3.
This patch adds some debug logging and documentation to the Python
2 virtualenv so that it is easier to diagnose issues that may arise
from running two different Python interpreters in re-entrant
multiprocess routines.
Differential Revision: https://phabricator.services.mozilla.com/D50819
--HG--
extra : moz-landing-system : lando
Homebrew on OS X will change Python's sys.executable to a custom value
which messes with mach's virtualenv handling code. Override Homebrew's
changes with the correct sys.executable value.
Differential Revision: https://phabricator.services.mozilla.com/D54602
--HG--
extra : moz-landing-system : lando
Build a full sysroot by downloading the `wasi-sdk` repo, which has `llvm-project` and `wasi-libc` as submodules. `wasi-sdk` builds a `clang` in a unique configuration (with `wasm32-wasi` as a default target) and uses that `clang` to build the rest of the pieces for the wasm sysroot.
In principle it should be possible to build the sysroot using our in-house automation-built `clang`, but I kept running into strange, hard-to-diagnose issues when I attempted that. If someone else is able to straighten out all the compilation issues, we could replace this script and stop pulling in `wasi-sdk` entirely, which would result in a build that takes much less time overall. Until then, this will have to do to unblock the rest of the wasm sandboxing work.
Differential Revision: https://phabricator.services.mozilla.com/D54560
--HG--
extra : moz-landing-system : lando
An error means that javadoc is being copied to the incorrect folder as the {project} variable is incorrectly formatted
Differential Revision: https://phabricator.services.mozilla.com/D54731
--HG--
extra : moz-landing-system : lando
