531384 - create a defined, straightforward procedure for respinning locales in a release

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[[e-mail] (:bhearsum)]

We've had to do this a couple of times i the 3.6 cycle, and it's pretty common in the beta/rc stage. The method used most recently was:
* Manually retag the locale repositories
* Delete current builds of the locale(s)
* Respin the builds with 'force build'
* Resign using a very rough manual process
* Generate updates for the locale(s), manually

In the past, we've done a more heavy handed approach be spinning a build2 and symlinking in most of the build1 content.

Whichever way we want to do it, we need to automate and document it.

Comment 1

[Chris Cooper [:coop] (he/him)]

Mass move of bugs from Release Engineering:Future -> Release Engineering. See http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

Comment 2

[[e-mail] (:bhearsum)]

It seems doubtful I'll be touching this any time soon

Comment 3

[Mike Taylor [:bear]]

does this cover the bug's request:

https://wiki.mozilla.org/Release:Release_Automation_on_Mercurial:Documentation#Need_to_rebuild_only_some_locales

Comment 4

[[e-mail] (:bhearsum)]

No, that's a bit different. This bug is talking about respinning a locale after signing/updates is finished. That section only covers triggering l10n builds that have failed prior to signing/updates.

Comment 5

[Mike Taylor [:bear]]

wanted to bump this to triage so it can be compared to the recent release automation work that has been done (and which I may not be following closely.)

Comment 6

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

found during triage. 

bhearsum: Can you review, and see how much of this still applies after all the automation improvements of the last 14months?

Comment 7

[[e-mail] (:bhearsum)]

So...there was two goals I had in mind when originally filing this:
1) Automate respinning of a single locale
2) Document the process

At this point, I feel that respinning of a single locale is rare enough and touches enough parts of the automation, that it's not worthwhile to automate it -- so let's forgote about that.

So, we just need to document how to do it, then. Here's an overview of what that process looks like today:
- Manually retag the locale's repository (**)
- Delete the current build of the locale
- Manually force the repack on each of the "$platform_standalone_repack" builders
- Manually sign it and update the *SUMS files (**)
- Manually create a partial MAR for the locale (**)
- Re-run update verify

Items marked with "**" need to be flushed out more, here's some links that would help in doing so:
https://wiki.mozilla.org/Releases/Firefox_3.6b4/BuildNotes#signing
https://wiki.mozilla.org/Releases/Firefox_3.6b4/BuildNotes#updates
https://wiki.mozilla.org/Release:Release_Automation_on_Mercurial:Documentation#Standalone_Repack_Builders

Comment 8

[Chris Cooper [:coop] (he/him)]

Using Ben's process and links from comment #7 as a basis, I've added a section on re-spinning a single locale to the release automation wiki:

https://wiki.mozilla.org/Release:Release_Automation_on_Mercurial:Documentation#Re-spinning_a_single_locale

Comment 9

[[e-mail] (:bhearsum)]

Awesome, thanks Coop!