Closed Bug 446380 Opened 17 years ago Closed 17 years ago

tracemonkey builds not reporting to mozillatest properly

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: shaver, Assigned: reed)

References

(
URL
)

Details

http://hg.mozilla.org/tracemonkey/index.cgi/rev/c315c24d0b90ca071d3325c4a0a4266bbaf3b4a8 was pushed 12 hours ago (http://hg.mozilla.org/tracemonkey/index.cgi/pushlog), but there has been no new build for any platform since that push. (It should fix the red for Win and Lin, at the least.)
If the timestamps on ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/tracemonkey-macosx/ are in GMT then the builds might be happening, but not reporting to MozillaTest tinderbox correctly?
Builds are definitely happening. I've also checked the logs and e-mail is *definitely* being sent to Tinderbox: 2008/07/21 04:08 PDT [Broker,7,10.2.71.210] ping finished: success 2008/07/21 04:08 PDT [Broker,7,10.2.71.210] <Build WINNT 5.2 tracemonkey build>.startBuild 2008/07/21 04:08 PDT [Broker,7,10.2.71.210] sending mail (362 bytes) to ['tinderbox-daemon@tinderbox.mozilla.org'] Given that *all* builds (not just tracemonkey or other buildbot driven ones) have dropped from MozillaTest I'm going to guess that it's a problem on that side. Can someone from Server ops have a look?
Assignee: nobody → server-ops
Component: Release Engineering → Server Operations
QA Contact: release → justin
Summary: tracemonkey buildbot not rebuilding on push → tracemonkey builds not reporting to mozillatest properly
I see two builds on http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaTest -- what are you seeing?
Right now I see the chatzilla build only, still no tracemonkey builds.
FWIW, I've got a couple builds going to MozillaExperimental that haven't disappeared. http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaExperimental
Assignee: server-ops → reed
Reed, what's the status here ? I checked just now and the MozillaTest tree was bare but it did have builds when I checked earlier today. Could this be fallout from the storage change to the tinderbox server ? Is there something special out the MozillaTest tree ? Appending &hours=24 to the url gets me a whole bunch of builds, including many that should be displayed on the standard 12 hour waterfall.
(In reply to comment #7) > Reed, what's the status here ? I checked just now and the MozillaTest tree was > bare but it did have builds when I checked earlier today. Could this be fallout > from the storage change to the tinderbox server ? Is there something special > out the MozillaTest tree ? I looked at this several hours ago, and it was full of boxen building, so I had counted it as WFM in my mind, but I guess not. This is really weird. There's nothing special or different about MozillaTest that I can see. I'll try to look at it again in a few hours after I've had some sleep. > Appending &hours=24 to the url gets me a whole bunch of builds, including many > that should be displayed on the standard 12 hour waterfall. Yeah, same here. So weird.
QA Contact: justin → mrz
(In reply to comment #8) > (In reply to comment #7) > > Reed, what's the status here ? I checked just now and the MozillaTest tree was > > bare but it did have builds when I checked earlier today. Could this be fallout > > from the storage change to the tinderbox server ? Is there something special > > out the MozillaTest tree ? > I looked at this several hours ago, and it was full of boxen building, so I had > counted it as WFM in my mind, but I guess not. This is really weird. There's > nothing special or different about MozillaTest that I can see. I'll try to look > at it again in a few hours after I've had some sleep. Any update on this? By continuously hitting shift-refresh, I had MozillaTest change, displaying one column, then two, then zero, then one column. > > Appending &hours=24 to the url gets me a whole bunch of builds, including many > > that should be displayed on the standard 12 hour waterfall. > Yeah, same here. So weird. Trying the &hours=24 trick showed me two columns, but there should be many more. fyi: I looked at the administer page to see if the undisplayed machines were present-but-unchecked. Instead, I note they were not even listed on the administer page at all?!?!
I think the build.dat file got corrupted. I moved it out of the way and created a new one. Let's see if that helps overnight.
Status: NEW → ASSIGNED
I moved Tracemonkey builds back to MozillaTest and kicked a few builds.
I just saw a Mac Talos machine totally drop as soon as Tracemonkey started reporting there again.
...and it just came back. (MacOSX Darwin 8.8.1 talos trunk stage is the machine in question).
The tracemonkey machines just dropped again.
Whiteboard: Still debugging; possible corrupt data files
Any update here?
So, I'm going to rebuild this tree from scratch.
Whiteboard: Still debugging; possible corrupt data files → Rebuilt tree; waiting to see if everything is ok
It's been ok the few times I've checked it today, fwiw.
Everything seems to be looking ok, save the broken *_dep_build machines.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: Rebuilt tree; waiting to see if everything is ok
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.