This patch fixes an issue where a suite was being found in the full path to the test which led to the baseline coverage tests being considered on a per-suite basis (like browser-chrome), when it should be on a per-file-extension basis for '.html' files. This is fixed by only considering the test name and excluding the full path to it.
Differential Revision: https://phabricator.services.mozilla.com/D5890
--HG--
extra : moz-landing-system : lando
Imports the changes to the UpdateVerifyConfig class, and sets --override-certs for staging releases.
Differential Revision: https://phabricator.services.mozilla.com/D5705
--HG--
extra : moz-landing-system : lando
Now that Linux PGO builds also do LTO and all the Linux builds use
clang, there's not much use for separate LTO builds.
Differential Revision: https://phabricator.services.mozilla.com/D5632
These are used if MOZ_UPDATE_CHANNEL is set, which isn't normally set on try.
However, when doing staging releases, that variable may be set. Populate the
mobile secrets with the default key that would be used without
MOZ_UPDATE_CHANNEL set on level-1 trees.
Differential Revision: https://phabricator.services.mozilla.com/D5599
--HG--
extra : moz-landing-system : lando
Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1482344 added workdir to the test_description_schema but
did not make it optinally_keyed_by test-platform. Since the Bitbar tests use different Docker images with
different layouts, we need the ability to set the workdir by test-platorm.
Bug 1484264 made changes to how the repackage tasks is configured.
The package-name field was hard-coded to "firefox". This field is later
used to build the Windows installer, and Thunderbird requires that it
be set to "thunderbird" or the build fails.
This patch changes package-name to be a templated field like the others.
Differential Revision: https://phabricator.services.mozilla.com/D5222
--HG--
extra : moz-landing-system : lando
We collect the classfiles from app and geckoview during the build task, but
before this patch we didn't use the app classfiles.
Depends on D4146
Differential Revision: https://phabricator.services.mozilla.com/D5167
--HG--
extra : moz-landing-system : lando
Rename the command and extend it to also archive Fennec class files into
another artifact, target.app_classfiles.zip.
Depends on D4142
Differential Revision: https://phabricator.services.mozilla.com/D4143
--HG--
extra : moz-landing-system : lando
Rather than trying to parse strings, just pass a json blob. This will allow us
to easily do things like mark artifacts to be left unextracted.
Differential Revision: https://phabricator.services.mozilla.com/D3553
--HG--
extra : rebase_source : 4e762c65d1c9f13361d5bae2e4608ba09bb39a91
This unbreaks some tier 3 raptor tasks. There are a few fixes rolled together here:
1) Stop overwriting the 'env' in mozharness_test.py's 'native-engine' implementation
2) Set the workdir to /home/cltbld (which makes sure the fetches are downloaded to there)
3) Download the fetches via mozharness in the 'raptor' script (since they don't use run-task anymore)
Depends on D3651
Differential Revision: https://phabricator.services.mozilla.com/D3652
--HG--
extra : moz-landing-system : lando
We need to grab fetches from several place in mozharness, this creates a
dedicated mixin that can be used from anywhere. If the 'fetch-content' script
is detected that will be used, otherwise we download the fetches manually.
Differential Revision: https://phabricator.services.mozilla.com/D3651
--HG--
extra : moz-landing-system : lando
The script was setting minidump_stackwalk_path, signalling that minidump_stackwalk
is expected to be found pre-installed at that location. When the path is not set,
the executable is downloaded.