454205 - (hg-auto-stage) create a master.cfg for doing staging runs of releases off of Mercurial

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Comment 1

[[e-mail] (:bhearsum)]

Attachment: staging factory for running Tag & Source off of Mercurial

This patch obviously integrates with our existing master, which lets us do slave sharing. In order to keep a good logical separation I put all of the release stuff in separate files. Arguably, we may want to share the "config" and only have a separate one for the actual schedulers/sources/steps. What do you think, Nick?

Comment 2

[[e-mail] (:bhearsum)]

Comment on attachment 337444 [details] [diff] [review]
staging factory for running Tag & Source off of Mercurial

ps, Once bug 447666 is resolved I can give this a full test. Going to try and get that done today.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 337444 [details] [diff] [review]
staging factory for running Tag & Source off of Mercurial

>diff -r 5f65905d2f18 mozilla2-staging/release_config.py

If there are no variables that are shared with nightlies then I quite like this separated out from the nightly config file (but you're not going to break my heart if you decide it's better combined).

>--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
>+++ b/mozilla2-staging/release_config.py	Mon Sep 08 09:44:00 2008 -0400
>@@ -0,0 +1,12 @@
>+mozillaCentral         = 'http://hg.mozilla.org/users/release_mozilla.com/mozilla-central/'

This is a neat use of the user repositories! Yay for not needing to setup our own VCS instance. But ...

>+mozillaCentralRevision = '6a6a0717bbfd'
>+relbranchOverride      = ''
>+baseTag                = 'FIREFOX_3_1b1'
>+l10nCentral      = 'http://hg.mozilla.org/users/release_mozilla.com/'

... how many l10n repos are you planning on cloning for testing ?

>+buildTools       = 'http://hg.mozilla.org/build/tools'

Nit: I hear trailing slashes are all the rage these days.

>diff -r 5f65905d2f18 mozilla2-staging/release_master.py
...
>+from buildbotcustom.misc import get_l10n_repositories
>+from buildbotcustom.process.factory import ReleaseTaggingFactory, \
>+  SingleSourceFactory

I see SingleSourceFactory on bug 452472, but where does get_l10n_repositories come from ?

>+tag_scheduler = Scheduler(
>+    name='tag',
>+    branch='release',

Could you remind me what setting branch to release is going to do ?

>+l10n_repos = get_l10n_repositories(l10nRevisionFile, l10nCentral,
>+                                   relbranchOverride)

This function excludes mozilla-central from the list ? Otherwise the shared root of the staging repo's (defined above) might cause you problems.

>+builders.append({
>+    'name': 'tag',
>+    'slavenames': ['moz2-linux-slave1', 'moz2-linux-slave02',
>+                   'moz2-linux-slave03', 'moz2-linux-slave05',
>+                   'moz2-linux-slave06'],

Just slave04 for staging, right ? Same again for the source slave.

Overall this is looking pretyt good, but I'd like to see get_l10n_repositories and see your responses to my queries.

Comment 4

[[e-mail] (:bhearsum)]

(In reply to comment #3)

> >+mozillaCentralRevision = '6a6a0717bbfd'
> >+relbranchOverride      = ''
> >+baseTag                = 'FIREFOX_3_1b1'
> >+l10nCentral      = 'http://hg.mozilla.org/users/release_mozilla.com/'
> 
> ... how many l10n repos are you planning on cloning for testing ?
> 

I hadn't thought too much about that. All in all, cloning a l10n repo takes approx. 30-40s. If we were to clone 60 locales it would take 30-45 minutes (which will increase as our l10n repositories get larger). This is about inline with our "prestage" and "cvsmirror" factories in 1.8/1.9 staging environments. Not that we should shoot to hit that time, but I don't think it's *too* bad.

If we feel it would be beneficial enough we could cut our list of locales used in staging.

> >diff -r 5f65905d2f18 mozilla2-staging/release_master.py
> ...
> >+from buildbotcustom.misc import get_l10n_repositories
> >+from buildbotcustom.process.factory import ReleaseTaggingFactory, \
> >+  SingleSourceFactory
> 
> I see SingleSourceFactory on bug 452472, but where does get_l10n_repositories
> come from ?
> 

Ah. This is just a helper function (which I helpfully forgot to attach). I'll put it up for review when I post a new version of the config.

> >+tag_scheduler = Scheduler(
> >+    name='tag',
> >+    branch='release',
> 
> Could you remind me what setting branch to release is going to do ?
> 

'branch' is used by changes (HgPoller) and can be set in 'sendchange' as well. Our HgPoller's add changes with branches of 'mozilla-central' or 'tracemonkey'. The Schedulers for those builders have their 'branch' attribute set to that as well. This is how Schedulers and ChangeSources are connected.

When a Scheduler has branch=None it will trigger builds when *any* changes come in. If the release Scheduler has branch=None it will kick off a run whenever somebody checks in to a repository we watch. (nb. we can work around the fileIsImportant attribute but it's a little unclean). By setting branch='release' we can kick-off automation with 'sendchange --branch=release ...'.

> >+l10n_repos = get_l10n_repositories(l10nRevisionFile, l10nCentral,
> >+                                   relbranchOverride)
> 
> This function excludes mozilla-central from the list ? Otherwise the shared
> root of the staging repo's (defined above) might cause you problems.
> 

I don't follow your comment here...get_l10n_repositories just reads the the l10nRevisionFile and returns a dict with all of the l10n repos and their details. Afterwards, we combine this dict with the one we've setup for mozilla-central. The keys of the dict are the full paths to the repositories, eg: 'http://hg.mozilla.org/users/release_mozilla.com/mozilla-central', 'http://hg.mozilla.org/users/release_mozilla.com/be'. I can't test this properly until we have a r/w hg.m.o account, but I'm *pretty* sure this will work.

> >+builders.append({
> >+    'name': 'tag',
> >+    'slavenames': ['moz2-linux-slave1', 'moz2-linux-slave02',
> >+                   'moz2-linux-slave03', 'moz2-linux-slave05',
> >+                   'moz2-linux-slave06'],
> 
> Just slave04 for staging, right ? Same again for the source slave.
> 

Duh, yeah.

Comment 5

[[e-mail] (:bhearsum)]

Attachment: address Nick's comments, add release configs

This patch addresses your comments Nick. I also added release configs to mozilla2-staging and as per bug 453438, s/release_mozilla.com/ffxbld_release.com/.

Comment 6

[[e-mail] (:bhearsum)]

Attachment: function for processing the l10n-changesets file

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #4)
> I hadn't thought too much about that. All in all, cloning a l10n repo takes
> approx. 30-40s...

I just meant that each clone to the user repo is using the ssh to hg.m.o, so 60 might be a little repetitive to do manually ;-). Probably a subset of locales is OK on staging.
 
> > Could you remind me what setting branch to release is going to do ?
> 'branch' is used by changes (HgPoller) and can be set in 'sendchange' as well...

Thanks for this, that's really helpful. What we do on 1.8 production confuses me though - the tag scheduler is using branch=None while we have two PeriodicScheduler's firing off en-US builds with branch = 'MOZILLA_1_8_BRANCH'.

> > This function excludes mozilla-central from the list ? Otherwise the shared
> > root of the staging repo's (defined above) might cause you problems.
>
> I don't follow your comment here...get_l10n_repositories just reads the the
> l10nRevisionFile ...

I was confused about where the l10nRevisionFile file comes from, and was imagining getting a list of repo's from http://hg.mozilla.org/users/release_mozilla.com/ (where mozilla-central would be next to lots of locales).

Comment 8

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 337648 [details] [diff] [review]
address Nick's comments, add release configs

Looks good, r+, but ...

>+ac_add_options --with-branding=browser/branding/unofficial

isn't needed for a beta and should be removed from the three mozconfigs.

Comment 9

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 337649 [details] [diff] [review]
function for processing the l10n-changesets file

Can we add an assertion for revision having value FIXME ? Otherwise r+.

Comment 10

[[e-mail] (:bhearsum)]

(In reply to comment #7)
> (In reply to comment #4)
> I just meant that each clone to the user repo is using the ssh to hg.m.o, so 60
> might be a little repetitive to do manually ;-). Probably a subset of locales
> is OK on staging.
> 

Well, if the patches in bug 453438 land we'll be able to do it automatically. (Sorry, probably should've mentioned that yesterday!)

> Thanks for this, that's really helpful. What we do on 1.8 production confuses
> me though - the tag scheduler is using branch=None while we have two
> PeriodicScheduler's firing off en-US builds with branch = 'MOZILLA_1_8_BRANCH'.
> 

Ah. Builds triggered from Schedulers and those triggered from ChangeSources work differently. We pass in the builder names to the Periodic scheduler which creates a BuildSet every N minutes. A BuildSet contains a SourceStamp (branch, revision, patch, changes) but also contains a list of Builders. When this gets submitted to the BuildMaster it bypasses the "Change" system and the other Schedulers never see it.

When HgPoller gets a change it calls BuildMaster.addChange() which simply forwards that change to all of the Schedulers. The Schedulers then decide whether they want to start a build or not (and if they do, end up submitting a BuildSet like in the Periodic example above).

Does that help?

Comment 11

[[e-mail] (:bhearsum)]

(In reply to comment #8)
> (From update of attachment 337648 [details] [diff] [review])
> Looks good, r+, but ...
> 
> >+ac_add_options --with-branding=browser/branding/unofficial
> 
> isn't needed for a beta and should be removed from the three mozconfigs.

Do we want --enable-official-branding? Looks like the 3.0 betas had that flipped on, http://bonsai.mozilla.org/cvsgraph.cgi?file=mozilla/tools/tinderbox-configs/firefox/linux/mozconfig&rev=1.18

Comment 12

[[e-mail] (:bhearsum)]

Attachment: [checked in] l10n helper function w/ assertion, as landed

RCS file: /cvsroot/mozilla/tools/buildbotcustom/misc.py,v
done
Checking in misc.py;
/cvsroot/mozilla/tools/buildbotcustom/misc.py,v  <--  misc.py
initial revision: 1.1
done

Comment 13

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #11)
> Do we want --enable-official-branding? Looks like the 3.0 betas had that
> flipped on,
> http://bonsai.mozilla.org/cvsgraph.cgi?file=mozilla/tools/tinderbox-configs/firefox/linux/mozconfig&rev=1.18

Yes, absolutely right.

Comment 14

[[e-mail] (:bhearsum)]

Attachment: [checked in] same as before w/ --enable-official-branding

changeset:   320:2a925d3bf897

Comment 15

[[e-mail] (:bhearsum)]

So, I'

Comment 16

[[e-mail] (:bhearsum)]

While getting a patch ready for staging repo set-up/tear I realized that if we are to do this in 'ffxbld's account we would need the *production* ffxbld key on our staging machines. I feel this is bad.

Two solutions here:
1) Put hg repos on staging-stage or another local VM location
2) Create a staging-ffxbld (or similar) account on hg.m.o, restrict it to only its' own user repositories.

Of the options I feel that 2) will be a more "real world" set-up. We'll be subject to the same restrictions, hooks, et. al that a real release would be.

How does this sound to people?

Comment 17

[[e-mail] (:bhearsum)]

Attachment: "prestage" factory for hg release staging

At the bottom of this page is a simply factory that tears down and re-clones all of the repositories the release will be using. That part's pretty straightforward, just two ssh commands on hg.m.o (these depend on the patch in 453438). The factory.py patch alos includes a bugfix in the base ReleaseFactory, and gets the subclasses calling the right __init__ method (just in case we end up overriding __init__ in ReleaseFactory.

In release_config I added a few extra vars that are needed for the repo tear-down/setup.

Finally, in release_master I added a repo_setup scheduler that fires ahead of Tag. Nothing complicated in that patch, I think.

Comment 18

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 338356 [details] [diff] [review]
"prestage" factory for hg release staging

>Index: factory.py
>===================================================================
>+class StagingRepositorySetupFactory(ReleaseFactory):
>+    def __init__(self, hgHost, username, sshKey, repositories):
>+        ReleaseFactory.__init__(self)
>+        for repo in sorted(repositories.keys()):
>+            repoName = self.getRepoName(repo)
>+            pushRepo = self.getPushRepo(repo)
>+
>+            self.addStep(ShellCommand,
>+             command=['ssh', '-l', username, '-i', sshKey,
>+                      'edit %s delete YES' % repoName],
>+            )
>+            self.addStep(ShellCommand,
>+             command=['ssh', '-l', username, '-i', sshKey,
>+                      'clone %s %s' % (repoName, repoName)]
>+            )
>+

Overall this looks pretty good to me, but what happens if you try to delete a repo that doesn't exist ? eg on first run, or adding a locale. There isn't quite enough context in attachment 337643 [details] [diff] to tell if it returns a non-zero exit status as well as writing to stderr.

Comment 19

[[e-mail] (:bhearsum)]

I'll test that out. The worst it can do is return non-zero, so I'll add haltOnFailure=False to these.

Comment 20

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #19)
> I'll test that out. The worst it can do is return non-zero, so I'll add
> haltOnFailure=False to these.

I don't think we should do that, it could mask errors creating the repos. How about a simple poll for existence before deleting ?

$ curl -I http://hg.mozilla.org/users/bsmedberg_mozilla.com/nnnnnnnarrf/
HTTP/1.1 404 Not Found
Date: Tue, 16 Sep 2008 01:03:03 GMT
Server: Apache/2.2.3 (Red Hat)
Content-Type: text/html; charset=UTF-8

Comment 21

[[e-mail] (:bhearsum)]

(In reply to comment #20)
> (In reply to comment #19)
> > I'll test that out. The worst it can do is return non-zero, so I'll add
> > haltOnFailure=False to these.
> 
> I don't think we should do that, it could mask errors creating the repos. How
> about a simple poll for existence before deleting ?
> 
> $ curl -I http://hg.mozilla.org/users/bsmedberg_mozilla.com/nnnnnnnarrf/
> HTTP/1.1 404 Not Found
> Date: Tue, 16 Sep 2008 01:03:03 GMT
> Server: Apache/2.2.3 (Red Hat)
> Content-Type: text/html; charset=UTF-8

Hmmm, yeah. I'll see what I can do here.

Comment 22

[[e-mail] (:bhearsum)]

Attachment: repo setup factory, test repo existence before attempting to delete

Comment 23

[[e-mail] (:bhearsum)]

I filed bug 455567 on getting a staging-ffxbld account created...

Comment 24

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 338875 [details] [diff] [review]
repo setup factory, test repo existence before attempting to delete

This is going to be complicated, in an attempt to avoid blocking - it's r+ with the caveats below.

I'm assuming the release_config, release_master, and l10n-changesets changes carry over from attachment 338356 [details] [diff] [review], with s/ffxbld/stage-ffxbld/.

>diff -r 067a056002a5 process/factory.py
...
>+class StagingRepositorySetupFactory(ReleaseFactory):
...
>+            commands = [
>+              # test for existence
>+              'wget %s' % repo,

This guy is going to create an index.html.n for each repo that already exists, and clutter up the place. It'd be good to avoid this but obviously not essential. We could cleanup afterwards with the python equiv of |rm index.html*| (and not fail if there are none!), or suppress it with |'wget -O- %s > /dev/null', % repo| (useful diagnostic output still goes to stderr).

>+              # delete it
>+              'ssh -l %s -i %s %s edit %s delete YES' % \
>+                (username, sshKey, hgHost, repoName),
>+              # create it again
>+              'ssh -l %s -i %s %s clone %s %s' % \
>+                (username, sshKey, hgHost, repoName, repoName)

I figured out what's worrying me here, it's going to try to go
      ssh ... http://hg.mozilla.org clone de de
instead of 
      ssh ... http://hg.mozilla.org clone l10n-central/de de
We need something else for the first repoName in clone, without affecting other users of getRepoName; this is mustfix before landing. If you're still blocked elsewhere then I'm happy to re-review, otherwise I'll take a gander post-landing.

Comment 25

[[e-mail] (:bhearsum)]

Attachment: updates to staging & tagging factories after test run

Two new things here:
1) The StagingRepoSetup factory will *always* try to clone the new repo. While running on staging I noticed that if the repo does not exist when the test run starts it will never try to create it. This is going to be a PITA, I think. So now, we only try to delete it if it exists, but we *always* try to clone. It's certainly not ideal, but I think it will work OK.
2) Added hgUsername/HgSshKey to ReleaseTaggingFactory. Turns out that we can't push without these, whould've thunk it!

Comment 26

[[e-mail] (:bhearsum)]

Attachment: [checked in] updates after first test run

New in this patch:
* Test a minimal number of locales (af, be).
* Use 'stage-ffxbld' as the hg user.

Comment 27

[[e-mail] (:bhearsum)]

Attachment: run MercurialBuildFactory for releases

Specifics:
* Bump Mercurial revision (mostly because I thought it would be fun to pick-up the 'mercurial changeset in application.ini' bug).
* Add 'releasePlatforms' in release_config.py

And then in release_master.py we just have a little loop like the dep/nightlies to, to create the builders. Note that we're mostly using the nightly config (on purpose, to reduce the chance of disparity between release+nightlies). I purposely have disabled uploadPackages since it drops them into latest-mozilla-central, which is silly. We do normally put release in dated directories ending in -branch (like -mozilla1.8), but I don't know why, honestly. I'm inclined to stop doing that if there's no reason to.

I intend to switch MercurialBuildFactory over to Ted's upload target when that's done, so I'll cross that bridge then.

Comment 28

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #27)
> And then in release_master.py we just have a little loop like the dep/nightlies
> to, to create the builders. Note that we're mostly using the nightly config (on
> purpose, to reduce the chance of disparity between release+nightlies). I

I like that production and staging configs are synced up, since that's the other type of disparity we have to care about when deploying this stuff for real.

> purposely have disabled uploadPackages since it drops them into
> latest-mozilla-central, which is silly. We do normally put release in dated
> directories ending in -branch (like -mozilla1.8), but I don't know why,
> honestly. I'm inclined to stop doing that if there's no reason to.

Do you mean that we currently upload releases to the likes of ...-firefox3.0.2, and then sync the files to the -candidates dir ? If so, that's part of the whole "keep a squillion copies so it's easy to go back one step in a manual proces" thing. We can probably just push into the candidates dir.

Comment 29

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 339131 [details] [diff] [review]
updates to staging & tagging factories after test run

r-

>diff -r 60edea960b39 process/factory.py
>+    def getRepoPath(self, hgHost, repo):
>+        repo.replace(hgHost, '')
>+        return repo.lstrip('/')

I must be missing something here, given this returns the source repo to clone from. The incoming repo is something like http://hg.mozilla.org/users/stage-ffxbld/mozilla-central/, right ? Not sure what the .replace is for given immutable strings. Hopefully this transformation map helps (or you can fix up my mental model!)
  <repo> 
     --> <dest> <source>
  http://hg.mozilla.org/users/stage-ffxbld/mozilla-central/
     --> mozilla-central mozilla-central
  http://hg.mozilla.org/users/stage-ffxbld/de
     --> de l10n-central/de
So essentially it's getRepoName and prepend 'l10n-central/' if it's not mozilla-central, or not *-central to be T'bird friendly.

Nit, I'd put getRepoPath with the other two get helpers.

>             self.addStep(ShellCommand,
>-             command=['hg', 'out', pushRepo],
>+             command=['hg', 'out', '-e',
>+                      'ssh -l %s %s' % (hgUsername, sshKeyOption),
>+                      '-f', pushRepo],

Why do you need to force here and in the actual push ? Does hg barf at a http(s) vs ssh difference ?

Otherwise looks fine.

Comment 30

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 339132 [details] [diff] [review]
[checked in] updates after first test run

>diff -r b17d3a904212 mozilla2-staging/release_config.py
>--- a/mozilla2-staging/release_config.py	Mon Sep 15 11:26:00 2008 -0400
>+++ b/mozilla2-staging/release_config.py	Wed Sep 17 17:07:18 2008 -0400
>@@ -1,12 +1,15 @@
>+hgHost            = 'hg.mozilla.org'
>+hgUsername        = 'stage-ffxbld'
>+hgSshKey          = '~cltbld/.ssh/ffxbld_dsa'

Urgh, kinda sucky to have both staging and production keys both named ffxbld. I wonder how I missed us starting that. Maybe we can fix that at some point.

r+

Comment 31

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 339136 [details] [diff] [review]
run MercurialBuildFactory for releases

>+        branch='mozilla-central',
>+        sourceRepo=mozillaCentral.replace('mozilla-central', ''),

Presumably you're removing mozilla-central from sourceRepo because the MercurialBuildFactory is going to add it back again (by setting baseURL & defaultBranch on the addStep(Mercurial)). I was gonna r+ this but then I see on staging that the Mercurial is trying to clone from
  http://hg.mozilla.org/users/stage-ffxbld/release
Given what you said earlier, is the 'release' coming from the branch on the tag_scheduler ?

Comment 32

[[e-mail] (:bhearsum)]

Comment on attachment 339132 [details] [diff] [review]
[checked in] updates after first test run

changeset:   350:9af7cb70bdb8

Comment 33

[[e-mail] (:bhearsum)]

Comment on attachment 339131 [details] [diff] [review]
updates to staging & tagging factories after test run

obsoleted by https://bugzilla.mozilla.org/attachment.cgi?id=340960&action=edit

Comment 34

[[e-mail] (:bhearsum)]

Attachment: staging release master updates

This updates the staging master to run ReleaseUpdatesFactory properly, along with a few couple of other things:
* use isHgPollerTriggered in dep/nightly schedulers and release scheduler
* Update for 3.1b2

Comment 35

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 343934 [details] [diff] [review]
staging release master updates

>diff -r a892e71f9495 mozilla2-staging/release_config.py
>+cvsroot           = ':ext:[e-mail]:/cvsroot'
>+patcherConfig     = 'moz191-branch-patcher2.cfg'

Won't the checkin of the updated patcherConfig fail ?

>diff -r a892e71f9495 mozilla2-staging/release_master.py
> repo_setup_scheduler = Scheduler(
>     name='repo_setup',
>-    branch='release',
>+    branch='mozilla-central',
>     treeStableTimer=0,
>-    builderNames=['repo_setup']
>+    builderNames=['repo_setup'],
>+    fileIsImportant=lambda c: not isHgPollerTriggered(c, nightly_config.HGURL)
> )

The isHgPollerTriggered lets you set the real branch ?

Looks fine otherwise.

Comment 36

[[e-mail] (:bhearsum)]

(In reply to comment #35)
> (From update of attachment 343934 [details] [diff] [review])
> >diff -r a892e71f9495 mozilla2-staging/release_config.py
> >+cvsroot           = ':ext:[e-mail]:/cvsroot'
> >+patcherConfig     = 'moz191-branch-patcher2.cfg'
> 
> Won't the checkin of the updated patcherConfig fail ?
> 

That's a really good point. Might be worthwhile adding a flag to control check-in of this in ReleaseUpdatesFactory. Not sure how else we could work around this. I guess we could set haltOnFailure=False for that step, but that's probably a bad thing to do.

> The isHgPollerTriggered lets you set the real branch ?
> 
> Looks fine otherwise.

Yeah, that's right. Both HgPoller triggered changes and the ones we'll be giving Buildbot through 'sendchange' will have mozilla-central as the branch - isHgPollerTriggered distinguishes between them.

Comment 37

[Nick Thomas [:nthomas] (UTC+12)]

Or we get back into the cvs mirroring game.

Comment 38

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 343934 [details] [diff] [review]
staging release master updates

>+useBetaChannel    = '0'

This should be a boolean I think (same in the release config pls), r+ with that.

Comment 39

[[e-mail] (:bhearsum)]

Attachment: [checked in] patch as landed

changeset:   430:e6c44bae2124

Comment 40

[[e-mail] (:bhearsum)]

Attachment: [checked in] add update_verify builders to staging release automation

Pretty straightforward....Note that I changed the tools repository to be /users/stage-ffxbld/tools. We'll have to update that when there's important changes. We could also go the route of PatcherConfig and have an option to not push the changes back.

Comment 41

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 346924 [details] [diff] [review]
[checked in] add update_verify builders to staging release automation

>diff -r 8c675383696e mozilla2-staging/release_config.py
>+buildTools        = 'http://hg.mozilla.org/users/stage-ffxbld/tools/'

Lets keep a close eye on keeping this in sync.

>diff -r 8c675383696e mozilla2-staging/release_master.py
>+    update_verify_factory = UpdateVerifyFactory(
...
>+        baseTag=baseTag,

This should be the tag for the previous release, eg 
  "%s_%s_RELEASE" % (productName.upper(), oldVersion.replace('.','_'))
Please fix on checkin.

...
>+        version=appVersion,

As I said on bug 462145 this makes my head hurt. I'll take two aspirin every morning, but don't let me get an ulcer!

>+    builders.append({
>+        'name': '%s_update_verify' % platform,
>+        'slavenames': pf['slaves'],

Aside: There are probably other places we can use this now that we have multiple slaves in staging.

Comment 42

[[e-mail] (:bhearsum)]

Comment on attachment 346924 [details] [diff] [review]
[checked in] add update_verify builders to staging release automation

changeset:   494:fc8e0e4e44cc

Comment 43

[[e-mail] (:bhearsum)]

Now that the initial config is setup I'm going to close this bug and we can take care of actually adding builders in the other dependent bugs -- that's what seems to be happening anyways.