merge buildbot 0.7.6 into our buildbot tree

RESOLVED FIXED

Status

P3
normal
RESOLVED FIXED
11 years ago
5 years ago

People

(Reporter: bhearsum, Assigned: preed)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
Just wanted to file this so we don't forget about it.
Priority: -- → P3
(Reporter)

Updated

11 years ago
Blocks: 400074
(Assignee)

Comment 1

11 years ago
I'll take a stab at this; I'm sure I'm gonna need some help with merging the code in, though.
Assignee: build → mozpreed
(Assignee)

Comment 2

11 years ago
I took a look at this on Thursday, and found out an interesting side effect of doing a CVS import, namely that for files that do not have merge conflicts, they "magically become HEAD."

That's... mostly fine, except for the fact that if you have dependencies on files that *do* have conflicts, you now have a broken state until you complete the merge (as opposed to being able to check the source in on the vendor branch, and merge it to head separately, which makes infinitely more sense).

Anyway, we'll have to do this import in a coordinated fashion; I talked to rhelmer, and he says that the release automation doesn't auto-pull buildbot; he believed the try server stuff doesn't either.

Bug 347947 talks about using a stable tag for tinderbox pulls, so we should probably do that for buildbot as well. I can apply a tag to the current state of the world and then do the import, and when we have a clean merge, update the production tag. That's easy enough to do, but I wanted to make sure that all the consumers of mozilla/tools/buildbot are *NOT* auto-pulling from CVS before I do this, since this is likely to break them if that's the case.

rhelmer, robcee, and bhearsum: that sound correct to you?
(Reporter)

Comment 3

11 years ago
None of the Buildbots I run auto-pull the tree. I don't know of any that do, either.
QA Contact: mozpreed → build
no, that shouldn't affect us. The unittest master just runs checkout on client.mk then does make -f client.mk checkout. I think we'll be ok there.
(Assignee)

Comment 5

11 years ago
Alright, when bug 401156 gets sorted out, I'll go ahead and tag mozilla/tools/buildbot with BUILDBOT_MOZILLA_PRODUCTION, do the import, get help with the merge ;-), and then we can test 0.7.6 by pulling head, and get at (our version) of 0.7.5 by pulling the _PRODUCTION tag.
That sounds fine to me. As long as we still have access to 0.7.5 in tree, we should be good to go. I don't think any of our existing (qa) systems will need further patching to 0.7.5 and I'd just as soon start working with the newer version (and have a place to drop our own patches if needed).
(Assignee)

Comment 7

11 years ago
Slight change of plans: there was some confusion on this, so we spent most of the day discussing the pros and cons (in little chunks on IRC).

The upshot: bhearsum and I will do the import/merge tomorrow morning, and
I've volunteered to create/maintain any possible 0.7.5 buildbot branch,
should it become necessary; right now, the prevailing opinion is, it won't,
and getting 0.7.6 in the tree is a way to merge our moz-specific 0.7.5
changes into 0.7.6, plus make more moz-specific 0.7.6 patches, if
necessary.

The currently deployed/working 0.7.5 code has been tagged with BUILDBOT_MOZILLA_PRODUCTION, and per CVS vendor branch procedure, upon import, non-modified files will become head.

There will be no 0.7.5 branch unless it becomes necessary.
(Assignee)

Comment 8

11 years ago
Created attachment 287555 [details] [diff] [review]
0.7.6 import conflicts merge

I just checked in Buildbot 0.7.6: 

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=&branchtype=match&dir=mozilla%2Ftools%2Fbuildbot&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-11-06+10%3A00&maxdate=2007-11-06+10%3A10&cvsroot=%2Fcvsroot

This patch is to resolve the generated conflicts; it's pretty big, because it includes files that were deleted; the files that have actual conflicts worth looking at are:

buildbot/changes/bonsaipoller.py
buildbot/status/tinderbox.py
buildbot/test/test_bonsaipoller.py

In the case of bonsaipoller.py and tinderbox.py, I picked our versions over the 0.7.6 versions, as bhearsum said our versions are more current.

In the case of test_bonsaipoller,py, I picked our revision, except for the addition of the testMissingRevisionResult method, which I would imagine couldn't hurt (but am not 100% sure; hence the r? ;-)
Attachment #287555 - Flags: review?(bhearsum)
(Reporter)

Comment 9

11 years ago
Comment on attachment 287555 [details] [diff] [review]
0.7.6 import conflicts merge

OK. The tinderbox.py and bonsaipoller.py changes are fine. We should take our version of test_bonsaipoller.py as well, that testcase was purposely dropped (because it was wrong). I thought Brian had took those changes, but it appears he missed them.

So, r+ to this w/ taking our version of test_bonsaipoller.py.
(Assignee)

Comment 10

11 years ago
(In reply to comment #9)

> So, r+ to this w/ taking our version of test_bonsaipoller.py.

Landed with you, per our sanity check convo on IRC this morning. (Thanks for that :-)

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=&branchtype=match&dir=mozilla%2Ftools%2Fbuildbot&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-11-08+10%3A00%3A00&maxdate=2007-11-08+10%3A10%3A00&cvsroot=%2Fcvsroot
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Reporter)

Comment 11

11 years ago
Comment on attachment 287555 [details] [diff] [review]
0.7.6 import conflicts merge

Removing review to remove it from my queue.
Attachment #287555 - Flags: review?(bhearsum)
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.