377229 - State lines are missing for some trees in quickparse

Status: RESOLVED FIXED

(Webtools Graveyard :: Tinderbox, defect)

Description

[Dave Miller [:justdave]]

Compare
http://tinderbox-stage.mozilla.org/showbuilds.cgi?quickparse=1&tree=SeaMonkey,Firefox,Thunderbird,Camino,XULRunner,Mozilla1.8,Sunbird,Mozilla1.8-SeaMonkey,Mozilla1.8.0,Sunbird-Mozilla1.8,MozillaTest
and
http://tinderbox.mozilla.org/showbuilds.cgi?quickparse=1&tree=SeaMonkey,Firefox,Thunderbird,Camino,XULRunner,Mozilla1.8,Sunbird,Mozilla1.8-SeaMonkey,Mozilla1.8.0,Sunbird-Mozilla1.8,MozillaTest

This is blocking updating production.  Production is currently running cvs from Jan 5 2007.  Something checked in since then broke this.

Comment 1

[Dave Miller [:justdave]]

(sorry if this is a dupe... I could swear we knew about this already, but I can't find the bug)

Comment 2

[cls]

Attachment: v1.0

It looks like the require() call is being cached even though it's inside an eval() statement.  This means that, for any particular bonsai_tree, the batchid.pl file is only actually being read once.  Since a number of the tinderbox trees share the same bonsai_tree, only the first tree is able to get its tree state.  This may explain the 'missing batchid.pl' warnings as well.

Comment 3

[Dave Miller [:justdave]]

Comment on attachment 261344 [details] [diff] [review]
v1.0

hmm, this doesn't solve the problem.  This has been live on tinderbox-stage for about an hour, and none of the State lines came back.

Comment 4

[cls]

Looking at the URLs from comment #0, some of the states came back.  Namely, the states of the Firefox, Thunderbird & camino trees.  

There's still a discrepancy in the output.  The production output shows that every tree has $bonsai_tree='SeaMonkey', which doesn't seem correct.

What does Mozilla1.8/treedata.pl show for $bonsai_tree ?  Does XULRunner/treedata.pl have $bonsai_tree set?

--- states-prod.txt	2007-04-12 09:04:32.671875000 -0700
+++ states-test.txt	2007-04-12 09:04:39.921875000 -0700
@@ -2,10 +2,9 @@
 State|Firefox|SeaMonkey|open
 State|Thunderbird|SeaMonkey|open
 State|Camino|SeaMonkey|open
-State|XULRunner|SeaMonkey|open
-State|Mozilla1.8|SeaMonkey|open
+State|Mozilla1.8|Mozilla1.8|open
 State|Sunbird|SeaMonkey|open
-State|Mozilla1.8-SeaMonkey|SeaMonkey|open
-State|Mozilla1.8.0|SeaMonkey|open
-State|Sunbird-Mozilla1.8|SeaMonkey|open
+State|Mozilla1.8-SeaMonkey|Mozilla1.8|open
+State|Mozilla1.8.0|Mozilla1.8.0|open
+State|Sunbird-Mozilla1.8|Mozilla1.8|open
 State|MozillaTest|SeaMonkey|open

Comment 5

[Dave Miller [:justdave]]

XULRunner/treedata.pl has:

$bonsai_tree='';

Comment 6

[Dave Miller [:justdave]]

I set it to SeaMonkey and now it works.

And this has also eliminated the batchid errors in cron related to the SeaMonkey tree.  However, the l10n ones are still happening.

No BatchID in /var/www/webtools/bonsai-cvs/data/l10n/batchid.pl

Comment 7

[Dave Miller [:justdave]]

And that problem appears to be caused because there is no l10n directory in Bonsai.

Comment 8

[cls]

Checking in showbuilds.pl;
/cvsroot/mozilla/webtools/tinderbox/showbuilds.pl,v  <--  showbuilds.pl
new revision: 1.21; previous revision: 1.20
done