1221054 - Mozilla Pulse messages for locale repacks need build status per locale

Status: RESOLVED WORKSFORME

(Release Engineering :: Release Automation, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

As of now any repack message only contains a single status but not for each individual locale. That makes it impossible for us to determine if we have to test a locale or not.

As best we should have the same structure as for the funsize update messages through TaskCluster. See bug 1215523 for getting support of that in pulsetranslator.

Not a hard-blocker for our work on bug 1221044 but definitely good to have.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

An example we have here:

http://archive.mozilla.org/pub/firefox/candidates/43.0b1-candidates/build1/logs/release-mozilla-beta-win64_repack_1-bm82-build1-build17.txt.gz

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Rail, also release promotion isn't doing it right, and only set the changeset of the (I think) accordingly l10n repo:

       [
          "locales",
          "cy:76cfd00faa96 da:3031ec912b7a de:bbf3507eb2d1 dsb:462887cb524c el:22b959c9a739 en-GB:686f94eff7a4 en-ZA:720d9153b07b eo:3230fe303c77 es-AR:20092952ee3f es-CL:e5de7280134f es-ES:c61c25b745c3 es-MX:bf870e599f70 et:ed26b69e4de8 eu:f309d2511247 fa:cb1546a801ba",
          "bbb"
        ],

Instead it should also tell the status of each locale. Something the mozharness scripts for l10n repacks of nightly builds are doing very well. Also it should be JSON object which can easily be parsed. The above structure would cause us to update our consumer code each time you want to add a new feature. Beside that I'm not sure what 'bbb' is for a locale.

My proposal:

> [
>   "locales",
>   "[\"cy\":{\"revision\": \"76cfd00faa96\", \"status\": \"Success"\}, ...]
> ]

Can we add this as blocker for the release promotion work?

Comment 3

[Rail Aliiev [:rail]]

 "locales", "cy:76cfd00faa96 ... is something that is set *before* the build starts and that property has no idea about the build status.

The repack script should set the same properties we see in nightly repacks, but I cannot confirm that now, because BBB is down and there was something that prevented it publishing properties.json (see https://tools.taskcluster.net/task-inspector/#TGqnuOkXQ8ujdOXPkGylkw/0)

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Oh I see. Most likely I was looking at the wrong pulse message then? This info came out of build.release-date_firefox_win32_l10n_repack.60.log_uploaded which I thought is the final message that this repack has been finished.