Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

hidden debug unittests showing up on tbpl

0 views
Skip to first unread message

L. David Baron

unread,
Nov 6, 2009, 2:10:53 PM11/6/09
to dev-tree-...@lists.mozilla.org
The current debug unittest blockers at:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=523385&hide_resolved=1
are all accumulating lots of comments today because, for some
reason, http://tests.themasta.com/tinderboxpushlog/ stopped honoring
the hidden state of the unit test machines that aren't ready to be
unhidden yet because of those blockers. In other words, there's a
lot of extra orange on tinderboxpushlog right now that's not
supposed to be there.

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

Daniel Holbert

unread,
Nov 6, 2009, 2:23:40 PM11/6/09
to dev-tree-...@lists.mozilla.org, L. David Baron
> reason, http://tests.themasta.com/tinderboxpushlog/ stopped honoring
> the hidden state of the unit test machines that aren't ready to be
> unhidden yet because of those blockers.

Those unit test machines are also showing up on the Firefox-Unittest
page now (which is why they'd be showing up on tbpl, I presume, since it
just pulls from Firefox-Unittest, right?)

Did Tinderbox stop honoring the hidden state of those test machines? Or
maybe they were un-hidden prematurely for some reason?

~Daniel

Chris AtLee

unread,
Nov 6, 2009, 2:26:28 PM11/6/09
to Daniel Holbert, L. David Baron, dev-tree-...@lists.mozilla.org
On 06/11/09 02:23 PM, Daniel Holbert wrote:
>> reason, http://tests.themasta.com/tinderboxpushlog/ stopped honoring
>> the hidden state of the unit test machines that aren't ready to be
>> unhidden yet because of those blockers.
>
> Those unit test machines are also showing up on the Firefox-Unittest
> page now (which is why they'd be showing up on tbpl, I presume, since it
> just pulls from Firefox-Unittest, right?)
>
> Did Tinderbox stop honoring the hidden state of those test machines? Or
> maybe they were un-hidden prematurely for some reason?

Yesterday we noticed that scraping was disabled for all of the Unittest
columns, so we must have accidentally unhidden some of the columns while
re-enabling scraping.

Did somebody disable scraping? Or maybe Tinderbox is getting Alzheimer's...


L. David Baron

unread,
Nov 6, 2009, 2:40:05 PM11/6/09
to dev-tree-...@lists.mozilla.org

No, they're still marked as not Active in
http://tinderbox.mozilla.org/admintree.cgi?tree=Firefox-Unittest

Maybe enabling scraping on a hidden box causes it to be unhidden?
However, I thought scraping was enabled on all of these already...

Daniel Holbert

unread,
Nov 6, 2009, 4:09:16 PM11/6/09
to dev-tree-...@lists.mozilla.org
I've just disabled scraping on these two boxes:
OS X 10.5.2 mozilla-central test debug mochitests-1/5
OS X 10.5.2 mozilla-central test debug mochitests-2/5
to see if that makes them hidden again...

Daniel Holbert

unread,
Nov 6, 2009, 8:48:42 PM11/6/09
to dev-tree-...@lists.mozilla.org

Interesting -- it looks like unchecking the "scrape" checkbox **has no
effect** right now.

For example, the most recent cycle on the "mochitests-2/5" box has this
shown on the Firefox-Unittest tinderbox page:
> mochitest-plain-2
> 9277/31/0
> mochitest-plain-2
> timeout

IIUC, this means it's behaving as if scrape was enabled (even though
this cycle started at 4:28 PM, over 3 hours after I unchecked 'scrape'
for that column).

So, it looks as if we're just completely ignoring the "active" and
"scrape" checkboxes on the "administer tinderbox" page. We're behaving
as if they're both checked, regardless of whether they are or not.

(FWIW: I'm re-checking 'scrape' for those boxes now, to clean up after
myself.)

~Daniel

Daniel Holbert

unread,
Nov 7, 2009, 12:57:31 PM11/7/09
to dev-tree-...@lists.mozilla.org
Filed this bug on the issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=527239

> _______________________________________________
> dev-tree-management mailing list
> dev-tree-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tree-management

Nick Thomas

unread,
Nov 8, 2009, 4:12:48 AM11/8/09
to
Did you spot the name change from

OS X 10.5.2 mozilla-central test debug mochitests-1/5
to
OS X 10.5.2 mozilla-central debug test mochitests-1/5
That happened when the old-style Linux unittest builds were disabled on
Thursday morning (PST), bug 507540. No doubt that'll be why I had to set
scraping to a bunch of debug and opt test builds a few hours afterward.

I've set all the 12 debug and opt testers as inactive for both win32 and
mac. If any of those should be active please set them correctly and
comment here.

Cheers,
Nick Thomas

L. David Baron

unread,
Nov 8, 2009, 11:51:17 AM11/8/09
to Nick Thomas, dev-tree-...@lists.mozilla.org
On Sunday 2009-11-08 22:12 +1300, Nick Thomas wrote:
> I've set all the 12 debug and opt testers as inactive for both win32 and
> mac. If any of those should be active please set them correctly and
> comment here.

The opt ones were all fine; I set those active again.

All of the windows debug ones were fine except for everythingelse
(blocked by bug 525356... and maybe more problems now) and
mochitests 5/5 (blocked by bug 524006... although it might not be
happening anymore), so I'm setting those active as well.

L. David Baron

unread,
Nov 8, 2009, 12:00:14 PM11/8/09
to dev-tree-...@lists.mozilla.org
On Sunday 2009-11-08 08:51 -0800, L. David Baron wrote:
> The opt ones were all fine; I set those active again.
>
> All of the windows debug ones were fine except for everythingelse
> (blocked by bug 525356... and maybe more problems now) and
> mochitests 5/5 (blocked by bug 524006... although it might not be
> happening anymore), so I'm setting those active as well.

I also unhid the windows everythingelse and the windows mochitests
5/5 since they seem to be green now (although we'll see if they stay
green enough).

0 new messages