These builds aren't ready for general availability, so we don't want to publish
them. But we want to start building them now.
Differential Revision: https://phabricator.services.mozilla.com/D17453
--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
This provides an easy way to encode an artifact URL in static data such as
taskcluster/ci/nightly-l10n/kind.yml, without knowing in advance the format of
the URL.
--HG--
extra : rebase_source : 5b5229d96aad2916b1b3c8e72045c1d461fc1c02
extra : source : 9c35dd209c6b407bc3a45ce7b4c27272ef1bb486
This provides an easy way to encode an artifact URL in static data such as
taskcluster/ci/nightly-l10n/kind.yml. This could be used in
mozharness_test.py, for example, as well -- but other code (such as to support
backfilling) expects `task-reference` there. To avoid breaking such subtle
bits, those can continue using `task-reference` with URLs generated based on
TASKCLUSTER_ROOT_URL.
Differential Revision: https://phabricator.services.mozilla.com/D14197
--HG--
extra : moz-landing-system : lando
If a task has `required_signoffs` that match a release's `required_signoffs`, we should defer running that task until we have a matching `signoff_url`.
- add filter_out_missing_signoffs
- add transforms changes to inherit upstream `required_signoffs`
- add `mar-signing` `required_signoffs` to the `partials-signing`, `mar-signing`, and `mar-signing-l10n` kinds
Differential Revision: https://phabricator.services.mozilla.com/D11734
--HG--
extra : moz-landing-system : lando
We want to defer mar-signing to the second half of the promote phase,
but we want to keep Windows repackaged exe signing in the first half of
the promote phase. This means we need to stop signing the complete MAR
in repackage-signing, and defer it to another kind.
Differential Revision: https://phabricator.services.mozilla.com/D11730
--HG--
extra : moz-landing-system : lando
Most jobs include at least one transform that verifies the input of all the
tasks against a schema. This code is duplicated in each transform. Refactor it,
so that we only need one copy of the logic.
Differential Revision: https://phabricator.services.mozilla.com/D12165
--HG--
extra : moz-landing-system : lando
Most jobs include at least one transform that verifies the input of all the
tasks against a schema. This code is duplicated in each transform. Refactor it,
so that we only need one copy of the logic.
Differential Revision: https://phabricator.services.mozilla.com/D12165
--HG--
extra : moz-landing-system : lando
If a task has `required_signoffs` that match a release's `required_signoffs`, we should defer running that task until we have a matching `signoff_url`.
- add filter_out_missing_signoffs
- add transforms changes to inherit upstream `required_signoffs`
- add `mar-signing` `required_signoffs` to the `partials-signing`, `mar-signing`, and `mar-signing-l10n` kinds
Differential Revision: https://phabricator.services.mozilla.com/D11734
--HG--
extra : moz-landing-system : lando
We want to defer mar-signing to the second half of the promote phase,
but we want to keep Windows repackaged exe signing in the first half of
the promote phase. This means we need to stop signing the complete MAR
in repackage-signing, and defer it to another kind.
Differential Revision: https://phabricator.services.mozilla.com/D11730
--HG--
extra : moz-landing-system : lando
This provides an easy way to encode an artifact URL in static data such as
taskcluster/ci/nightly-l10n/kind.yml, without knowing in advance the format of
the URL.
--HG--
extra : rebase_source : 25c99d392e9b71c514f236379a816fae971e161a
The phase of a task doesn't depend on which phase graph it is being generated in.
Differential Revision: https://phabricator.services.mozilla.com/D8303
--HG--
extra : moz-landing-system : lando
Make 52 -> 60 updates signed with the old mar scheme (instead of mar_384)
Differential Revision: https://phabricator.services.mozilla.com/D5244
--HG--
extra : moz-landing-system : lando
This is needed to not have a circular kind dependency when we actually spell out all dependencies (in a following patch)
Differential Revision: https://phabricator.services.mozilla.com/D1695
--HG--
rename : taskcluster/ci/repackage-signing/kind.yml => taskcluster/ci/repackage-signing-l10n/kind.yml
extra : rebase_source : c2998ba23f213090d27495eb44c3bde3a1628dff
for L10n jobs should run per-push based on the corresponding builds
Differential Revision: https://phabricator.services.mozilla.com/D1406
--HG--
extra : rebase_source : 207d1c25e37ab2619a09fb209282ffe55025de26
for L10n jobs should run per-push based on the corresponding builds
Differential Revision: https://phabricator.services.mozilla.com/D1406
--HG--
extra : rebase_source : 902aaff764db6df06b96e7ba8c7d717afd6869e3
This merely extends the logic involved in shipping language packs to AMO. All devedition language packs will be shipped as 'unlisted' for now, meaning that there is no extra AMO work involved. The extension ID is taken from the langpack itself.
Differential Revision: https://phabricator.services.mozilla.com/D1104
--HG--
extra : rebase_source : a6fcc953c79531377540216343e9d0037a2879d6
On ESR[60] stub installer isn't designed to work, and we expect most users of esr will have no use for a stub installer. However this poses some problems where the taskgraph assumes that any Nightly generates a stub installer and thus it should be available along the way.
The patch hardcodes the list of branches that do not need a stub installer, though we'll want to clean up this specification in some way, as Thunderbird will likely need it to be cleaner and we may want on-change builds to use this logic (e.g. for on-change l10n).
Differential Revision: https://phabricator.services.mozilla.com/D1082
--HG--
extra : source : 2f091908b8839650961c3968b6beee1dd8d1084b
