If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

moz2 tinderboxes should log information about what config and clobber file they use



Release Engineering
9 years ago
4 years ago


(Reporter: dbaron, Assigned: bear)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [automation][tinderbox][triagefollowup])

When we were on CVS, build tinderboxes had information like this at the beginning of the log:

-->Tinderbox Config Info<--------------------------
Begin: Sat Jul 26 09:38:07 2008
cvs stat
cvs status: Examining .
File: CLOBBER          	Status: Up-to-date

   Working revision:	1.56
   Repository revision:	1.56	/cvsroot/mozilla/tools/tinderbox-configs/firefox/macosx/CLOBBER,v
   Sticky Tag:		(none)
   Sticky Date:		(none)
   Sticky Options:	(none)

File: mozconfig        	Status: Up-to-date

   Working revision:	1.17
   Repository revision:	1.17	/cvsroot/mozilla/tools/tinderbox-configs/firefox/macosx/mozconfig,v
   Sticky Tag:		(none)
   Sticky Date:		(none)
   Sticky Options:	(none)

File: tinder-config.pl 	Status: Up-to-date

   Working revision:	1.48
   Repository revision:	1.48	/cvsroot/mozilla/tools/tinderbox-configs/firefox/macosx/tinder-config.pl,v
   Sticky Tag:		(none)
   Sticky Date:		(none)
   Sticky Options:	(none)

End:   Sat Jul 26 09:38:08 2008
-->END Tinderbox Configuration Information<--------------

(This is from "MacOSX Darwin 8.8.4 bm-xserve08 Depend Universal Nightly on 2008/07/26 09:38:00" on http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox3.0 .)

I don't see any equivalent in the log of "OS X 10.5.2 mozilla-central build on 2008/07/26 09:18:36" on http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox .  I wanted it just now because I wanted to know which CLOBBER file to commit to in order to clobber that machine (although I'm not even sure if there is one).

Information about what configuration and clobber files are being used should be printed in the log for the new tinderboxes.

Comment 1

9 years ago
Clobbering is bug 432236, and isn't enabled yet.
Yeah, this probably won't end up being relevant for clobbering. Is there a reason why we need to print the location of the mozconfig even though we're echoing it out? I think it's fairly obvious where it lives, and trivial to find out for those who don't already know.
It's not obvious to me where it lives.  Is it still in CVS?  If so, are the CVS trunk tinderboxes using CVS trunk and the mozilla-central ones using a tag, or vice-versa?  Where would I find out if I didn't know?  I don't even know where all the buildbot source and scripts live.
Well, presumably if you need to know where they live you're going to be modifying them. In that case, you'll certainly be in contact with someone who knows where they are.

I don't really feel that strongly about this, so you feel it's really important I won't argue against it anymore...
Component: Release Engineering → Release Engineering: Future
Priority: -- → P3

Comment 5

8 years ago
Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering


8 years ago
Assignee: nobody → bear


7 years ago
Whiteboard: [automation][tinderbox][triagefollowup]

Comment 6

7 years ago
Marking this as WorksForMe as I have learned the following while discussing the bug:

We output the hg step that retrieves the Mozconfig and we also output the Mozconfig - this is in the log.

We now do clobbers in a totally different manner so the build has nothing to output if I understand it correctly.

So the data is available, albeit in different places
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.