449583 - update mozilla/tools/buildbot to version 0.7.9

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[[e-mail] (:bhearsum)]

Comment 1

[[e-mail] (:bhearsum)]

Buildbot 0.7.9 is being release next week. May as well go straight to it.

Comment 2

[[e-mail] (:bhearsum)]

Gotta do this before 3.1b1.

Comment 3

[[e-mail] (:bhearsum)]

Here's the strategy for importing this:
* Create a BUILDBOT_0_7_7_BRANCH, in case we need to land fixes for Buildbot's still using it.
* Import Buildbot 0.7.9

After this is done we will be in this state:
* The current (Buildbot 0.7.7) code will still be tagged as BUILDBOT_MOZILLA_PRODUCTION and have a branch to land on if needed (BUILDBOT_0_7_7_BRANCH)
* mozilla/tools/buildbot's tip will be Buildbot 0.7.9 plus a few patches (the same ones we've got on the current, 0.7.7, trunk).

Comment 4

[Armen [:armenzg]]

How do you keep track of these patches?

Comment 5

[[e-mail] (:bhearsum)]

Whenever I'm preparing to do an import I create a CVS mirror of our repository locally, do a 'cvs import' of the new version there, and then diff that new tree with the tarball I imported...there's a more detailed explanation of this process in bug 425390

Comment 6

[[e-mail] (:bhearsum)]

Attachment: diff of vanilla 0.7.9 w/ our tree after conflict resolution in a test import

I've done a test import on a local CVS mirror that went pretty smoothly.

I had to do some conflict resolution in tinderbox.py because of bug 433874, which didn't make it upstream.

There was a conflict in test_bonsaipoller.py/bonsaipoller.py - upstream fixed a bug in one of the tests (http://buildbot.net/trac/changeset/675).

Our tree currently contains an hgpoller.py - the upstream one doesn't. The copy of HgPoller we use lives in buildbotcustom (because it quite mozilla-specific) - I intend to delete the one in buildbot/changes/hgpoller.py as part of this import. I've looked in CVS and Mercurial buildbot-configs and the only master.cfg referencing it is moz2unit in CVS, which is not in use anywhere (the moz2 unittest configs live in Mercurial).

Our tree also contains tinderboxpoller.py which *is* in use by our 1.8/1.9 automation setups. We copied TinderboxPoller into Buildbotcustom at one point but we have not updated the masters to use it yet. This will stay in our Buildbot tree after this import.

Our tree contains two patches in slave/commands.py. One is SetMozillaBuildProperties, which MozillaStageUpload depends on. The other is a fix to make HgPoller triggered Mercurial builds work properly. This patch hasn't landed upstream yet due to problems that we haven't hit. We need this for our dep and nightly builds and thus it will stay in our tree after this import.

Comment 7

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

(In reply to comment #6)
> Our tree currently contains an hgpoller.py - the upstream one doesn't. The copy
> of HgPoller we use lives in buildbotcustom (because it quite mozilla-specific)
> - I intend to delete the one in buildbot/changes/hgpoller.py as part of this
> import. I've looked in CVS and Mercurial buildbot-configs and the only
> master.cfg referencing it is moz2unit in CVS, which is not in use anywhere (the
> moz2 unittest configs live in Mercurial).

Am I reading the patch wrong? It looks like the conflict checkout is *adding* hgpoller.py rather than taking it away. Or are you just not going to check it in?

Comment 8

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

Comment on attachment 340939 [details] [diff] [review]
diff of vanilla 0.7.9 w/ our tree after conflict resolution in a test import

(In reply to comment #7)
> Am I reading the patch wrong? It looks like the conflict checkout is *adding*
> hgpoller.py rather than taking it away. Or are you just not going to check it
> in?

r+ with hgpoller.py removed.

Comment 9

[[e-mail] (:bhearsum)]

Import and conflict resolution is complete. I ran unit tests on the new tree:
Ran 339 tests in 290.461s

PASSED (skips=27, successes=312)

Comment 10

[Armen [:armenzg]]

Does it make sense to branch buildbotcustom OR to import to hg.m.o/build?

L10n repackages can be done in an easier way in buildbot 0.7.8 by using scheduler's properties and the stuff that has been committed to buildbotcustom/l10n would have to be modified (which is not a problem but for the sake of leaving unused code behind)

What do you think?