Closed Bug 373510 Opened 14 years ago Closed 14 years ago

Non-Windows unit test tinderboxen are broken due to local checkout "change"

Categories

(Infrastructure & Operations :: RelOps: General, task)

task
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Waldo, Assigned: rcampbell)

References

Details

Currently the Windows and Linux tinderboxen which run tests are broken.  They're broken almost certainly because browser/components/sidebar/src/nsSidebar.js got clobbered during the recent change from that file being not preprocessed to preprocessed.  This change triggered an additional bug, bug 373362, which caused the nsSidebar.js in the checked-out tree to be overwritten with an empty file.

I don't think there's a way to affect the srcdir of a tinderbox, so I can't do anything to resolve this problem.  Someone's going to have to remove the empty nsSidebar.js and kick the machines so that the build can succeed.
The perf test machines seem ok (they don't do checkout or build), Jeff to you mean qm-rhel02 and qm-rhel02 xserve01 (looks like they are currently busted on the trunk)? These are buildbot machines in the QA network administered by robcee (changing component to Core/Testing).
Assignee: server-ops → nobody
Component: Server Operations: Tinderbox Maintenance → Testing
Product: mozilla.org → Core
QA Contact: justin → testing
Version: other → unspecified
Yes, I meant exactly those machines; I wasn't aware they weren't under the general purview of IT.
Moving back to serverops; if someone has access then please fix, otherwise we'll need to escalate to robcee (or, the tree is closed until Monday).
Assignee: nobody → server-ops
Component: Testing → Server Operations: Tinderbox Maintenance
Product: Core → mozilla.org
QA Contact: testing → justin
Version: unspecified → other
Severity: major → critical
deleted the offending file, clobbered and rebuilt. Should be fixed. I'll keep an eye on it and resolve when builds are finished.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Is there a way to get these machines to use the existing Tinderbox auto-clobber support?
There's no reason we couldn't. I understand the tinderboxes watch a file in build/ for update and do a clobber if it's touched? That would be a trivial buildstep to write.
(In reply to comment #6)
> There's no reason we couldn't. I understand the tinderboxes watch a file in
> build/ for update and do a clobber if it's touched? That would be a trivial
> buildstep to write.

Sort of; Tinderbox does something somewhat convoluted, and if the unit testing boxen aren't using anything tinderbox related (beyond maybe the mail-portion part), then we shouldn't emulate the way it's done there.

What would be useful is to monitor the state of the CLOBBER file in the repository, so developers can clobber their own builds via CVS, like they can with (most) tinderboxen.

The file watching stuff you're talking about above has to do with nightly builds, and it's how we "fake" a clobber.

Find me on IRC if you want the details of the CVS CLOBBER file stuff; I don't know if the mozconfigs are checked into [public] CVS, but it would be nice to put those along side them (this may be part of the buildbot config bug).
ok, we can talk about this and the alternative that presented itself on the buildbot devel list. I have a feeling we'll want to implement both of them.
Assignee: server-ops → rcampbell
Component: Server Operations: RelEng → RelOps
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.