This part removes the use_toolchains transform, and adjusts all task
definitions accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D41891
MANUAL PUSH: avoid closing autoland while docker images and toolchains
are rebuilt.
The 3-tier PGO builds used a separate mozconfig called 'profile-use' for
the final tier. This created a problem when it rode to beta, since the
same mozconfig was used for all trees, which meant we ended up with
nightly branding on beta builds.
With the PGO-enabling logic in common mozconfigs, we can enable it by
setting the MOZ_PGO_PROFILE_USE environment variable from the task
definition. All of the final-tier PGO builds now use the nightly, beta,
etc mozconfigs like before, so branding should be intact.
Differential Revision: https://phabricator.services.mozilla.com/D33172
--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
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
Some groups of tasks need to share the same profile data. For example,
Android PGO builds and Android Nightly builds both use the
generate-profile-android-api-16/pgo task for profile data. Previously
this was done with a text substitution, but this is a bit hacky and
doesn't easily scale with different build types.
Allowing use_pgo to be a string means we can just directly point to the
generate-profile task that contains the profile data to be used in a PGO
build.
Differential Revision: https://phabricator.services.mozilla.com/D29247
--HG--
extra : moz-landing-system : lando
this change adds support for parallel gcp builds for the following android build configurations:
- android-api-16
- opt
- debug
- android-x86
- opt
- android-x86_64
- opt
- debug
- android-aarch64
- opt
- debug
implementation notes:
- this patch mostly mirrors the equivalent windows-on-gcp patch at: https://phabricator.services.mozilla.com/D24865
- gcp builds are triggered with a treeherder tier 3 flag so that they are only displayed in the treeherder ui when the user has a tier 3 flag set.
- gcp builds use a th build symbol of "Bg" to make them easy to differentiate from ec2 builds in the treeherder ui.
- gcp builds use a perfherder "gcp" flag to make them easier to differentiate from ec2 builds in the perfherder ui.
Differential Revision: https://phabricator.services.mozilla.com/D26584
--HG--
extra : moz-landing-system : lando
There's a guard to prevent action, but it's confusing to ask for it
and then not take the action. Let's not ask. I'm leaving the guard,
pointless as it should be, just in case.
Differential Revision: https://phabricator.services.mozilla.com/D14828
--HG--
extra : moz-landing-system : lando
This patch is based on the cmake cache files for Android checked in to the
clang repo.
Differential Revision: https://phabricator.services.mozilla.com/D14004
--HG--
extra : moz-landing-system : lando
This has never been as useful as anticipated: we really aren't seeing
resource mismatches in the wild that need diagnostic aids.
Differential Revision: https://phabricator.services.mozilla.com/D12792
--HG--
extra : moz-landing-system : lando
This has never been as useful as anticipated: we really aren't seeing
resource mismatches in the wild that need diagnostic aids.
Depends on D12791
Differential Revision: https://phabricator.services.mozilla.com/D12792
--HG--
extra : moz-landing-system : lando
Bug 1492663 upgraded those builds to clang 7, and bug 1503330 brought
them back to clang 6 because of speedometer regressions.
With the previous change, the regression doesn't happen any more,
allowing to upgrade again.
Depends on D12394
Differential Revision: https://phabricator.services.mozilla.com/D12395
--HG--
extra : moz-landing-system : lando