Localized Repacks now visible on (most) pushes

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Localized Repacks now visible on (most) pushes

Justin Wood
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-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Localized Repacks now visible on (most) pushes

Gregory Szorc-3
On Wed, May 30, 2018 at 10:08 AM, Justin Wood <[hidden email]> 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-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Localized Repacks now visible on (most) pushes

Kim Moir-2
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 <[hidden email]> wrote:

> On Wed, May 30, 2018 at 10:08 AM, Justin Wood <[hidden email]> 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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-platform
>
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n