Incremental effort to improve android-hw device availability: Stop running android-hw
debug jsreftest and jittest on integration branches.
Also, remove the option for android-hw opt jittest on try. opt is a nice alternative
to pgo on try in general, but the risk of accidental (unnecessary) inclusion in
try pushes makes this a luxury we cannot afford on android-hw.
Differential Revision: https://phabricator.services.mozilla.com/D33156
--HG--
extra : moz-landing-system : lando
This follows the model set down for EME artifacts:
- a new tier is added that uses a new Python build action to fetch and
artifacts
- the action unpacks the fetched artifacts and moves specific inputs
into places expected by the build and packager
- in automation, MOZ_ARTIFACT_TASK* is used to ensure the artifacts
come from the correct tasks
In this case, the artifact fetching is done entirely in a new Python
build action that internally uses `mach artifact install --job ...`.
The action also verifies that the fetched artifacts are compatible and
that we're not assembling a fat AAR that is nonsensical. The specific
inputs are not used in the Fennec APK that is produced; they're only
used in the GeckoView AAR that is produced.
The artifact fetching itself required tweaking to fetch only
`target.maven.zip` artifacts and to not unpack them.
The specific inputs used are the native libraries (libs/$ARCH/*.so)
and the architecture-specific preference files ($ARCH/greprefs.js and
defaults/pref/$ARCH/geckoview-prefs.js). None of these inputs are
impacted by l10n.
Differential Revision: https://phabricator.services.mozilla.com/D31572
--HG--
extra : moz-landing-system : lando
Test suite changes:
- test-verify, marionette, firefox UI, wdspec, mochitest-a11y suites are migrated over to macosx1014 platform (green without requiring intervention)
Test expected outcomes:
- skip `browser/components/urlbar/tests/browser/browser_locationBarCommand.js` test as per comments in 1554807
Differential Revision: https://phabricator.services.mozilla.com/D33066
--HG--
extra : moz-landing-system : lando
Changes:
- separate the test-sets used by android-hw-p2-8-0-arm7 to `opt` and `pgo`
- remove `jsreftests` from `opt` build type
Differential Revision: https://phabricator.services.mozilla.com/D33072
--HG--
extra : moz-landing-system : lando
Changes:
- default chunk count is now set to 2
- added exception rules to maintain current chunk count (3) for slower platforms and build types
Differential Revision: https://phabricator.services.mozilla.com/D32929
--HG--
extra : moz-landing-system : lando
Taskcluster didn't correctly apply the change back to tier-3 in the previous patch because the wildcard setting the tier to 2 by default beat out the specific line setting tier-3 for the geckoview tests. This patch specifically changes the tier for non-geckoview reftests (fennec runs on x86 emulators) to tier-2, while geckoview reftests (TRA runs on x86_64 emulators) to tier-3.
This change also explicitly sets the non-reftest tests to tier-2 for all android platforms, because they didn't have the permafails that the reftests seem to have.
Differential Revision: https://phabricator.services.mozilla.com/D32863
--HG--
extra : moz-landing-system : lando
Some debug info for system packages are not available to valgrind in the
valgrind docker image, some of which are for libraries actively used by
Firefox. Not all of them, unfortunately, have debug info available, but
some of them do and we add them all. We could skip a few that are not
really useful, but that doesn't make a significant difference to the
docker image size (~0.3%).
Differential Revision: https://phabricator.services.mozilla.com/D32419
--HG--
extra : moz-landing-system : lando
Changes:
- add `jsreftest` to the list of permitted tests to run on `android-hw-p2-8-0-arm7-api-16`
- add necessary mozharness setup for `android-hw` for jsreftest
- disable `android-em` from running jsreftests
Differential Revision: https://phabricator.services.mozilla.com/D32262
--HG--
extra : moz-landing-system : lando
Changes:
__mochitest__
- demote `android-em` to tier 2
- promote `android-hw` to tier 1
- expand regex for `run-on-projects` specification to include all `android-em` instances, and restrict to `try`
Differential Revision: https://phabricator.services.mozilla.com/D32541
--HG--
extra : moz-landing-system : lando
Validate taskgraph parameters using a schema.
Previously, parameters were verified using handwritten comparison to a sample set of parameters.
Switch to using an explicit schema instead.
Differential Revision: https://phabricator.services.mozilla.com/D23756
--HG--
extra : moz-landing-system : lando
The last use of scm level in mozharness is in `mozharness.mozilla.secrets` which
uses the `MOZ_SCM_LEVEL` environment variable directy.
Differential Revision: https://phabricator.services.mozilla.com/D20897
--HG--
extra : moz-landing-system : lando
Changes:
- enabled SM(p) runs on `windows10-aarch64` for `built-projects`
- turn off `jittest` runs for all platforms matching `android-hw-.*-aarch64/.*`
Differential Revision: https://phabricator.services.mozilla.com/D32220
--HG--
extra : moz-landing-system : lando
Changes:
- demote all existing `android-em-4.*` tests to tier 2
- ensure the above tests only run on `try` and `mozilla-central` but with exceptions
Differential Revision: https://phabricator.services.mozilla.com/D32086
--HG--
extra : moz-landing-system : lando
Changes:
- demote all existing `android-em-4.*` tests to tier 2
- ensure the above tests only run on `try` and `mozilla-central` but with exceptions
Differential Revision: https://phabricator.services.mozilla.com/D32086
--HG--
extra : moz-landing-system : lando
This change is necessary to make either e10s profiling or LLVM IR-based
PGO instrumentation work properly, as both will generate multiple
`.profraw` files.
Differential Revision: https://phabricator.services.mozilla.com/D32390
--HG--
extra : moz-landing-system : lando
when update-verify migrated from using build-tools to in-tree, the path
to `diff-summary.log` was not updated.
Differential Revision: https://phabricator.services.mozilla.com/D32403
--HG--
extra : moz-landing-system : lando
Typo when I first landed this, but nothing relied on it so it didn't matter.
Differential Revision: https://phabricator.services.mozilla.com/D32009
--HG--
extra : moz-landing-system : lando
Changes:
- removed UBUNTU_1604 detection mechanism at top of `test-linux.sh` file, since all tests are run on Ubuntu 16.04 anyway
- added new environment value `NEED_COMPIZ`, defaulting to `true`, which will inform the test if compiz is required for tests
- from `test-linux.sh` remove unconditional invocation of compiz, and replace it with detection of `NEED_COMPIZ` environment variable
Differential Revision: https://phabricator.services.mozilla.com/D31724
--HG--
extra : moz-landing-system : lando
I had been waiting for more complete x86_64 coverage, but realized that's
not strictly necessary: TV works okay as-is on Android x86_64.
Differential Revision: https://phabricator.services.mozilla.com/D32347
--HG--
extra : moz-landing-system : lando
Bug 1553584 was filed and shows a race condition in the test harness that could make fixing bugs difficult. Bumping these back to tier-3 until that can be fixed.
Differential Revision: https://phabricator.services.mozilla.com/D32240
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Changes:
- edited `linux32-tests` to include only web-platform-tests
- removed references to other `linux32` platforms from `test-platforms.yml` other than `linux32-shippable/opt`
Differential Revision: https://phabricator.services.mozilla.com/D29792
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
This will match the compiler version Tor would like. We backport several
llvm-objcopy patches that landed right after the 8 branch though. We
also grab some upstream changes from mingw-clang in the build script
Differential Revision: https://phabricator.services.mozilla.com/D31347
--HG--
extra : moz-landing-system : lando
This patch runs wpt against opt and debug builds of geckoview as tier-2 jobs on mozilla-central and try.
Differential Revision: https://phabricator.services.mozilla.com/D31581
--HG--
extra : moz-landing-system : lando
This adds a new set of update tasks and channels for testing updates from the
previous ESR release, before we make the new release generally available as an
update.
Differential Revision: https://phabricator.services.mozilla.com/D31654
--HG--
extra : moz-landing-system : lando
ESR 68.2 is going to be the watershed for bz2 updates, so generate them for the
moment.
Differential Revision: https://phabricator.services.mozilla.com/D31652
--HG--
extra : moz-landing-system : lando
When the logic was switched to be by release-type, rc's were accidentally
excluded.
Differential Revision: https://phabricator.services.mozilla.com/D31587
--HG--
extra : moz-landing-system : lando
Stub installers aren't generated on esr branches; the repackage task includes
metadata indicating this. Use this information to filter out upstream artifacts
when use declarative artifacts.
Differential Revision: https://phabricator.services.mozilla.com/D31586
--HG--
extra : moz-landing-system : lando
When snaps started being packaged on archive.mozilla.org, the `build_platform`
of the snap repackge task changed, causing the beetmover dependencies to be
dropped. Switch the platform back so that the dependencies are restored.
Differential Revision: https://phabricator.services.mozilla.com/D31585
--HG--
extra : moz-landing-system : lando
we're looking to reduce costs on infra. as parallel gcp builds have served their purpose of demonstrating they are possible and valid, we'd now like to disable them until a later date.
Differential Revision: https://phabricator.services.mozilla.com/D31655
--HG--
extra : moz-landing-system : lando
These chunks are quite out of balance: Probably there are some very long running
tests in xpcshell-7 with 8 chunks. Even so, I think the easiest way to avoid timeouts
is to return to 12 chunks.
Differential Revision: https://phabricator.services.mozilla.com/D31685
--HG--
extra : moz-landing-system : lando
