470715 - 1.9.0 l10n buildslaves lose track of CVSROOT

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

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

After a fresh checkout, the Mac and Linux l10n buildslaves on the 1.9.0 branch (fx-mac-1.9-slave2 and fx-linux-1.9-slave2) will build happily for several cycles before they suddenly start throwing this error:

cvs checkout: existing repository /cvsroot/CVSROOT/Emptydir does not match /cvsroot/mozilla
cvs checkout: ignoring module mozilla/client.mk

I'm unsure what's causing this yet. The CVSROOT is coming from the config file, so it *should* be either always working or always not.

The complete command that is failing is:

cvs -q -z3 -d :ext:[e-mail]:/cvsroot co mozilla/client.mk mozilla/nsprpub mozilla/other-licenses/7zstub/firefox

From casual testing, it appears that updating the client.mk file on its own works fine, so splitting this step into two parts seems like a logical solution.

Comment 1

[Armen [:armenzg]]

I have found that in the L10nMixin when initiaized:
http://mxr.mozilla.org/mozilla/source/tools/buildbotcustom/l10n/scheduler.py#42
there is never an initialization of self.cvsRoot in the __init__ function and the default value is probably meaningless since on the function NightlyL10n the cvsRoot is already initialized to None and therefore it stays with that value (if not mistaken)

I wish I had used kwargs properly depending if repoType was "cvs" or "hg" instead of optional parameters

Comment 2

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

(In reply to comment #1)
> there is never an initialization of self.cvsRoot in the __init__ function and
> the default value is probably meaningless since on the function NightlyL10n the
> cvsRoot is already initialized to None and therefore it stays with that value
> (if not mistaken)

I've added a "self.cvsRoot = cvsRoot" to the __init__ section, and I've restarted the master.

Comment 3

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

Attachment: Update client.mk on its own.

Simply setting cvsRoot didn't help.

It appears we hit the above error when mozilla/client.mk actually has updates pending. By splitting the cvs into two parts and updating client.mk before the other modules, we avoid the error.