Re: Localized Repacks now visible on (most) pushes
Congratulations Callek! I know this was a tremendous amount of work on your side to implement and coordinate. Thank you for all your efforts to drive this forward, it has unblocked a lot of future l10n work. Kim On Wed, May 30, 2018 at 1:57 PM, Gregory Szorc wrote: > On Wed, May 30, 2018 at 10:08 AM, Justin Wood wrote: > > > Hello Everyone, > > > > tl;dr You should now see "L10n" jobs on treeherder with many pushes, > these > > are tier 1 and if they break they would also be breaking Nightly so your > > patch would need to be backed out. > > > > As many of you know, especially the old guard [1] here, Localized Repacks > > have frequently been known to fail in weird and interesting ways on > Nightly > > and Beta builds. > > > > Throughout the movement to taskcluster we have been reducing the > > differences in automation to make what we ship to release users happen > with > > the same process as what we ship to nightly users. We have recently > > achieved that parity now that we have finished our migration to > taskcluster > > [2] > > > > One straggler was on our implementation of L10n builds on try [3][4] > which > > had begun to frequently fail when users add/remove any localized file > (.dtd > > or .ftl). And similarly we have always lacked the ability to easily vet a > > change to central/inbound/autoland as "will this break l10n". > > > > With the work I've now done we have aligned this "try" l10n job with what > > we perform in the Nightly and Release Promotion process, as well as > allowed > > ourselves the ability to run these on every push. > > > > Implementation details: > > * For now these still run only when a subset of files change [5] but this > > list can be expanded easily, or we can rip it out and instead *always* > run > > these jobs. > > * These jobs are performed using live L10n repositories, but just a small > > set of our total localization, specifically: en-CA, he, it, ja, ja-JP-mac > > [6] > > * As part of doing this work, we needed to specify the STUB Installer > > differently, if we need it on any new channels/builds we need to specify > it > > in the build taskcluster kind, like [7]. We have a check in configure to > > error if its not set correctly [8] > > > > If you have any questions, feel free to reach out to me/releng. > > ~Justin Wood (Callek) > > > > Thank you, Justin and everyone else who worked on this! l10n packaging has > historically suffered from a lack of visibility in CI and lack of > understanding outside its small circle of maintainers. Moving the l10n > automation to Taskcluster and giving it visibility in Treeherder as part of > regular jobs that normal people see will go a very long way to increasing > understanding of l10n packaging. It also paves the road for overhauling the > technical underpinnings of l10n packaging. For those not aware, l10n > packaging has historically been a major burden for build system maintainers > because of the convoluted ways it interacts with the build system. Let's > just say that we have actively avoided touching code related to l10n out of > fear that it will break a convoluted system. Now that the l10n CI can more > easily be toggled and tested, it is substantially easier to iterate on and > we now have the confidence that our changes won't break things. This is a > game changer and will directly enable us to perform some long-overdue > refactoring of l10n code. Thank you! > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Localized Repacks now visible on (most) pushes
On Wed, May 30, 2018 at 10:08 AM, Justin Wood wrote: > Hello Everyone, > > tl;dr You should now see "L10n" jobs on treeherder with many pushes, these > are tier 1 and if they break they would also be breaking Nightly so your > patch would need to be backed out. > > As many of you know, especially the old guard [1] here, Localized Repacks > have frequently been known to fail in weird and interesting ways on Nightly > and Beta builds. > > Throughout the movement to taskcluster we have been reducing the > differences in automation to make what we ship to release users happen with > the same process as what we ship to nightly users. We have recently > achieved that parity now that we have finished our migration to taskcluster > [2] > > One straggler was on our implementation of L10n builds on try [3][4] which > had begun to frequently fail when users add/remove any localized file (.dtd > or .ftl). And similarly we have always lacked the ability to easily vet a > change to central/inbound/autoland as "will this break l10n". > > With the work I've now done we have aligned this "try" l10n job with what > we perform in the Nightly and Release Promotion process, as well as allowed > ourselves the ability to run these on every push. > > Implementation details: > * For now these still run only when a subset of files change [5] but this > list can be expanded easily, or we can rip it out and instead *always* run > these jobs. > * These jobs are performed using live L10n repositories, but just a small > set of our total localization, specifically: en-CA, he, it, ja, ja-JP-mac > [6] > * As part of doing this work, we needed to specify the STUB Installer > differently, if we need it on any new channels/builds we need to specify it > in the build taskcluster kind, like [7]. We have a check in configure to > error if its not set correctly [8] > > If you have any questions, feel free to reach out to me/releng. > ~Justin Wood (Callek) > Thank you, Justin and everyone else who worked on this! l10n packaging has historically suffered from a lack of visibility in CI and lack of understanding outside its small circle of maintainers. Moving the l10n automation to Taskcluster and giving it visibility in Treeherder as part of regular jobs that normal people see will go a very long way to increasing understanding of l10n packaging. It also paves the road for overhauling the technical underpinnings of l10n packaging. For those not aware, l10n packaging has historically been a major burden for build system maintainers because of the convoluted ways it interacts with the build system. Let's just say that we have actively avoided touching code related to l10n out of fear that it will break a convoluted system. Now that the l10n CI can more easily be toggled and tested, it is substantially easier to iterate on and we now have the confidence that our changes won't break things. This is a game changer and will directly enable us to perform some long-overdue refactoring of l10n code. Thank you! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Localized Repacks now visible on (most) pushes
Congratulations Justin! Excited to see this coming all together. With this change, we can now both improve our software quality and culture of paying attention to red L10n in treeherder :) Thank you! zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Localized Repacks now visible on (most) pushes
Hello Everyone, tl;dr You should now see "L10n" jobs on treeherder with many pushes, these are tier 1 and if they break they would also be breaking Nightly so your patch would need to be backed out. As many of you know, especially the old guard [1] here, Localized Repacks have frequently been known to fail in weird and interesting ways on Nightly and Beta builds. Throughout the movement to taskcluster we have been reducing the differences in automation to make what we ship to release users happen with the same process as what we ship to nightly users. We have recently achieved that parity now that we have finished our migration to taskcluster [2] One straggler was on our implementation of L10n builds on try [3][4] which had begun to frequently fail when users add/remove any localized file (.dtd or .ftl). And similarly we have always lacked the ability to easily vet a change to central/inbound/autoland as "will this break l10n". With the work I've now done we have aligned this "try" l10n job with what we perform in the Nightly and Release Promotion process, as well as allowed ourselves the ability to run these on every push. Implementation details: * For now these still run only when a subset of files change [5] but this list can be expanded easily, or we can rip it out and instead *always* run these jobs. * These jobs are performed using live L10n repositories, but just a small set of our total localization, specifically: en-CA, he, it, ja, ja-JP-mac [6] * As part of doing this work, we needed to specify the STUB Installer differently, if we need it on any new channels/builds we need to specify it in the build taskcluster kind, like [7]. We have a check in configure to error if its not set correctly [8] If you have any questions, feel free to reach out to me/releng. ~Justin Wood (Callek) [1] - https://en.wikipedia.org/wiki/Old_Guard [2] - https://atlee.ca/blog/posts/migration-status-3.html [3] - https://bugzilla.mozilla.org/show_bug.cgi?id=848284 [4] - https://bugzilla.mozilla.org/show_bug.cgi?id=1458378 [5] - https://hg.mozilla.org/integration/mozilla-inbound/annotate/d7472bf663bd/taskcluster/ci/l10n/kind.yml#l177 [6] - https://hg.mozilla.org/integration/mozilla-inbound/rev/d2f587986a3b [7] - https://hg.mozilla.org/integration/mozilla-inbound/diff/e250856b4688/taskcluster/ci/build/windows.yml [8] - https://hg.mozilla.org/integration/mozilla-inbound/rev/a562a809e8dc ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
