1277640 - desktop_l10n.py should clone gecko by revision for release repacks

Status: RESOLVED FIXED

(Release Engineering :: Release Automation: Other, defect, P1)

Description

[Rail Aliiev [:rail]]

Hit this in 45.2.0 ESR, when we started 2 release processes in parallel and the old one bumped the version on default, what caused "make wget_en_US" fail, because it was trying to download 42.0.0esrpre version.

Comment 1

[Justin Wood (:Callek)]

Supported by passing --revision to desktop_l10n.py fwiw.

Comment 2

[Rail Aliiev [:rail]]

doesn't look too hard to fix

Comment 3

[Rail Aliiev [:rail]]

Attachment: Bug 1277640 - desktop_l10n.py should clone gecko by revision a=release DONTBUILD

Review commit: https://reviewboard.mozilla.org/r/57292/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/57292/

Comment 4

[Rail Aliiev [:rail]]

(In reply to Justin Wood (:Callek) from comment #1)
> Supported by passing --revision to desktop_l10n.py fwiw.

we pass the revision via properties (cannot use --revision, which requires a reconfig), but the revision is hardcoded to "default" in the configs.

Comment 5

[Justin Wood (:Callek)]

https://reviewboard.mozilla.org/r/57292/#review54122

https://dxr.mozilla.org/mozilla-central/search?q=path%3Asingle_locale+default&redirect=false

Has a whole bunch of config files you may need/want to change this on, while your change at least protects release... there is also the matter of ensuring that setting %(revision)s works for the CI-based ones (on try) properly.

https://wiki.mozilla.org/ReleaseEngineering/TryServer#Desktop_l10n_jobs

Comment 6

[Rail Aliiev [:rail]]

TBH, I less worried about other types ATM. Release l10n repacks first, then we can look at other types.

Comment 7

[Justin Wood (:Callek)]

Comment on attachment 8759294 [details]
Bug 1277640 - desktop_l10n.py should clone gecko by revision  a=release DONTBUILD

https://reviewboard.mozilla.org/r/57292/#review54144

My desire for the try run was primarily so we can ensure this is actually supported, and doesn't break with this and future l10n work on this script.

That said, if it does work I'm ok r+'ing it. Also the --revision passing could be done via `--revision WithProperties(..)` anyway and not need a new reconfig for each release aiui. But in the end, if this works its already written and ok. (I was just hoping to avoid extra complexity in this already complex and weird-assumption-ridden script)

Comment 8

[Justin Wood (:Callek)]

(In reply to Rail Aliiev [:rail] from comment #6)
> TBH, I less worried about other types ATM. Release l10n repacks first, then
> we can look at other types.

Please file a new bug for followup cases though.

Comment 9

[Rail Aliiev [:rail]]

I'll land this next week.

Comment 10

[Rail Aliiev [:rail]]

looks like it requires https://hg.mozilla.org/mozilla-central/rev/e879961960ee, which added revision to runtime config vars.

Comment 11

[Rail Aliiev [:rail]]

(In reply to Justin Wood (:Callek) from comment #8)
> (In reply to Rail Aliiev [:rail] from comment #6)
> > TBH, I less worried about other types ATM. Release l10n repacks first, then
> > we can look at other types.
> 
> Please file a new bug for followup cases though.

This is bug 1250626

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5e0c246f9a60
desktop_l10n.py should clone gecko by revision r=Callek a=release DONTBUILD

Comment 13

[Rail Aliiev [:rail]]

Comment on attachment 8759294 [details]
Bug 1277640 - desktop_l10n.py should clone gecko by revision  a=release DONTBUILD

https://hg.mozilla.org/integration/mozilla-inbound/rev/5e0c246f9a60

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/5e0c246f9a60