We use autograph-prod for our ci, nightly, and release signing. Autograph-stage doesn't have the same guarantees for availability, so pointing, say, dep-signing at autograph-stage would have resulted in occasional tree closures whenever autograph-stage changes configuration or is down.
However, we also want a way to verify autograph-stage is still valid, after the autograph team makes changes. This task is meant to be add-task'ed; a green result means autograph-stage has signed the mar file correctly.
Differential Revision: https://phabricator.services.mozilla.com/D20749
--HG--
extra : moz-landing-system : lando
Two new kinds are introduced - 'instrumented-build' and
'generate-profile'. The instrumented-build kind is almost identical to
the build kind, except it can be used earlier in the task graph. The
3-tier PGO process becomes:
instrumented-build -> generate-profile -> build
The final build stage is identical to any other build, except it has
the 'use-pgo' flag set to True in its task definition. This flag causes
the transforms to add the instrumented-build and generate-profile tasks
to the taskgraph.
Differential Revision: https://phabricator.services.mozilla.com/D15750
--HG--
extra : moz-landing-system : lando
This changes a bunch of symbols, notably:
* Group name BMR-L10n(*) ==> BMR(*)
* Group name BM-L10n(*) ==> BM(*)
* Groups the BMR symbol itself for en-US Nightly [so BMR ==> BMR(N)]
* Groups the BM symbol itself for en-US Nightly [so BM ==> BM(N)]
* Changes Source Signing fron symbol Bs to Srcs
* Groups Source signing beetmoving as BM(Srcs) instead of symbol BM-S
* Balrog complete update submission changes from c-Up(N) to c-Up(Ns) [Fennec Only]
* Beetmover en-US changes from symbol BM-S to BM(Ns) [used in Fennec]
* Beetmover Checksums (en-US) changes from BMcs(N) => BMcs(Ns) [fennec]
* Checksums signing (en-US, fennec) changes from cs(N) => cs(Ns)
* [Asan] Balrog changed [c-UP(N) ==> c-UP(BoR)]
* [Asan] signing changed from Ns to BoRs
* [Asan] checksums signing changed from cs(N) to cs(BoR)
* [Asan] Change generated source uploading from Ugs ==> UgsBoR
Differential Revision: https://phabricator.services.mozilla.com/D4178
--HG--
extra : moz-landing-system : lando
Supports partner builds on esr60 by re-arranging how we specify the manifest repositories, which are different for esr60 compared to beta+release. The defaults for enabling partners and EME-free now depend on the partner-urls definition in taskcluster/ci/config.yml.
This patch also adds support for partner & EMEfree repacks in try staging releases, for all the various release branches. It makes release_level available early in the decision task (for the release promotion action) where a Parameters object is not available. Signing worker type is no longer hard-coded, and we use level-1 secrets for querying Github (via bug 1513375).
Differential Revision: https://phabricator.services.mozilla.com/D15185
--HG--
extra : moz-landing-system : lando
Rap-P treeherder group for Raptor power tests.
Emit separate PERFHERDER_DATA for power in addition to the performance measurements.
Use magic --host HOST_IP value to have framework load host ip from environment
variable HOST_IP.
Although this task technically doesn't build a toolchain, the set of
steps it needs to do is very similar to what a toolchain build does, so
we're shoehorning this task into the toolchain kind. The task basically
runs `cargo vendor` on the gfx/wr/Cargo.lock file (if/when it changes)
and exports a tarball of the resulting vendored crates. This allows
downstream tasks that build stuff in gfx/wr to not have to re-fetch
these crates from crates.io on every test run.
Differential Revision: https://phabricator.services.mozilla.com/D14406
--HG--
extra : moz-landing-system : lando
also rename the partials_signing transform to mar_signing.
Differential Revision: https://phabricator.services.mozilla.com/D11731
--HG--
rename : taskcluster/taskgraph/transforms/partials_signing.py => taskcluster/taskgraph/transforms/mar_signing.py
extra : moz-landing-system : lando
also rename the partials_signing transform to mar_signing.
Differential Revision: https://phabricator.services.mozilla.com/D11731
--HG--
rename : taskcluster/taskgraph/transforms/partials_signing.py => taskcluster/taskgraph/transforms/mar_signing.py
extra : moz-landing-system : lando
This creates 32-bits variants of the same packages that were added for
64-bits builds, with a few additions:
- python-defaults, so that the python package can be installed as a
dependency of the libglib2.0-dev package,
- xkeyboard-config, so that the xkb-data package can be installed as a
dependency of the libxkbcommon0 package.
Additionally, because the 32-bits and 64-bits packages are built
separately (the 32-bits packages can't, on Wheezy, be built on a 64-bits
host), they don't end up with the same
changelog.Debian/changelog.Debian.gz file because of a timestamp within
it. One way to address this would be to make the taskgraph more complex,
by adding a task creating the source package, and then two tasks
building the 32-bits and 64-bits binary packages from that source, but
that's not worth the overhead, when a simple hack works around the
problem: We make dpkg skip installing the changelog.Debian* files.
Differential Revision: https://phabricator.services.mozilla.com/D11140
This creates 32-bits variants of the same packages that were added for
64-bits builds, with a few additions:
- python-defaults, so that the python package can be installed as a
dependency of the libglib2.0-dev package,
- xkeyboard-config, so that the xkb-data package can be installed as a
dependency of the libxkbcommon0 package.
Additionally, because the 32-bits and 64-bits packages are built
separately (the 32-bits packages can't, on Wheezy, be built on a 64-bits
host), they don't end up with the same
changelog.Debian/changelog.Debian.gz file because of a timestamp within
it. One way to address this would be to make the taskgraph more complex,
by adding a task creating the source package, and then two tasks
building the 32-bits and 64-bits binary packages from that source, but
that's not worth the overhead, when a simple hack works around the
problem: We make dpkg skip installing the changelog.Debian* files.
Differential Revision: https://phabricator.services.mozilla.com/D11140
This creates 32-bits variants of the same packages that were added for
64-bits builds, with a few additions:
- python-defaults, so that the python package can be installed as a
dependency of the libglib2.0-dev package,
- xkeyboard-config, so that the xkb-data package can be installed as a
dependency of the libxkbcommon0 package.
Additionally, because the 32-bits and 64-bits packages are built
separately (the 32-bits packages can't, on Wheezy, be built on a 64-bits
host), they don't end up with the same
changelog.Debian/changelog.Debian.gz file because of a timestamp within
it. One way to address this would be to make the taskgraph more complex,
by adding a task creating the source package, and then two tasks
building the 32-bits and 64-bits binary packages from that source, but
that's not worth the overhead, when a simple hack works around the
problem: We make dpkg skip installing the changelog.Debian* files.
Differential Revision: https://phabricator.services.mozilla.com/D11140
This duplicates all web-platform-test mozharness based tests except with
dom.serviceWorkers.parent_intercept set to true.
Differential Revision: https://phabricator.services.mozilla.com/D8916
--HG--
extra : moz-landing-system : lando
This commit also removes dwarf-exceptions from the x64 build.
sjlj exceptions are needed on x86 because there is a bug currently involving
SEH exceptions on x86. However on x64 there is not, so we can use the
default SEH and get rid of dwarf exceptions. Additionally, to use SEH
exceptions, we need to -fuse-cxa-atexit
Differential Revision: https://phabricator.services.mozilla.com/D7759
--HG--
extra : moz-landing-system : lando
This commit also removes dwarf-exceptions from the x64 build.
sjlj exceptions are needed on x86 because there is a bug currently involving
SEH exceptions on x86. However on x64 there is not, so we can use the
default SEH and get rid of dwarf exceptions. Additionally, to use SEH
exceptions, we need to -fuse-cxa-atexit
Differential Revision: https://phabricator.services.mozilla.com/D7759
--HG--
extra : moz-landing-system : lando
This duplicates all the mochitest, based tests except with
dom.serviceWorkers.parent_intercept set to true. For now they are only run on
mozilla-central with linux64/debug.
Differential Revision: https://phabricator.services.mozilla.com/D7641
--HG--
extra : moz-landing-system : lando
This duplicates all the mochitest, based tests except with
dom.serviceWorkers.parent_intercept set to true. For now they are only run on
mozilla-central with linux64/debug.
Differential Revision: https://phabricator.services.mozilla.com/D7641
--HG--
extra : moz-landing-system : lando
This duplicates all the mochitest, based tests except with
dom.serviceWorkers.parent_intercept set to true. For now they are only run on
mozilla-central with linux64/debug.
Differential Revision: https://phabricator.services.mozilla.com/D7641
--HG--
extra : moz-landing-system : lando
This duplicates all the reftest tasks except with
dom.serviceWorkers.parent_intercept set to true. For now they are only run on
mozilla-central with linux64/debug.
Depends on D7480
Differential Revision: https://phabricator.services.mozilla.com/D7481
--HG--
extra : moz-landing-system : lando
The release-update-verify-config task requires that the versions passed
to it match up with what's been released. The version of Thunderbird
does not necessarily match the Gecko version it's based on.
Depends on D6509
Differential Revision: https://phabricator.services.mozilla.com/D6510
--HG--
extra : moz-landing-system : lando
This runs the jsshell benchmarks against Google's V8 engine in addition to spidermonkey.
Both shells will run in the same task to keep things simple and decluttered. Though we
could split them out to separate tasks at a later date if needed.
Differential Revision: https://phabricator.services.mozilla.com/D3356
--HG--
extra : moz-landing-system : lando
Having to define them explicitly feels too redundant for my liking.
I believe we didn't do this before because we were defining things
in terms of "using: fetch-url." Now that we are using a custom
transform, we can have nice things.
Differential Revision: https://phabricator.services.mozilla.com/D1575
--HG--
extra : rebase_source : e4b08bf799f4011904df0194035527ec625123dd
extra : intermediate-source : 3bb31648056bf9d7760c59420d26de25fbf2b268
extra : source : 52c528fe192df9b1704f4d24274b2adb435763ce
Having to define them explicitly feels too redundant for my liking.
I believe we didn't do this before because we were defining things
in terms of "using: fetch-url." Now that we are using a custom
transform, we can have nice things.
Differential Revision: https://phabricator.services.mozilla.com/D1575
--HG--
extra : rebase_source : 74639800c735d2c90b110b5c378eed570fdc3863
extra : amend_source : 92364ad0061c87bf111f6f11ba5bf39d8bfbe619
extra : intermediate-source : 825f0caef542f1b33376fbcc81dc18b915bf218b
extra : source : 52c528fe192df9b1704f4d24274b2adb435763ce
