445794 - refactor mozilla2/master.cfg so the keys of the 'branches' dict aren't assumed to be repository names

Status: RESOLVED DUPLICATE of bug 465735

(Release Engineering :: General, defect, P3)

Description

[[e-mail] (:bhearsum)]

We've run into this when trying to set-up XULrunner builds off of m-c. We can't add branches['mozilla-central-xulrunner'] because 'mozilla-central-xulrunner' is not a repository. We can't add branches['mozilla-central']['win32-xulrunner'] without doing hacky things in the body of the loop. It's time to remove this assumption from the config. It's probably as simple as adding branches[name]['repository'] and changing the main loop to use that.

Comment 1

[[e-mail] (:bhearsum)]

I'm an awful, awful person for letting this sit for so long. I'll get started on this now.

Comment 2

[[e-mail] (:bhearsum)]

Attachment: refactor master.cfg

Important parts of this patch include;
* Moving the HgPoller generation outside of the main loop. When we actually solve the bug this is blocking we'll end up with two "branches" which have 'mozilla-central' as their repository. This patch will make sure we only ever have 1 HgPoller per repository.
* Names of Schedulers, builders, build directories have not been touched. We can't switch them to be 'repository' instead of 'name' because they have uniqueness requirements.
* The 'branch' attribute of Schedulers and HgPollers has changed to 'repository'.

This patch should have no effect on current functionality - it simply enables us to solve the dep bug.

Comment 3

[[e-mail] (:bhearsum)]

Attachment: same thing for production

I've tested the previous patch well in staging, now here's the production version. (Same patch, just against different files).

Comment 4

[[e-mail] (:bhearsum)]

I'm not planning to land this until xr builds get enabled...back in the pool for now.

Comment 6

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

Moving closed Future bugs into Release Engineering in preparation for removing the Future component.