Closed
Bug 478096
Opened 15 years ago
Closed 15 years ago
leak test machines report red when they should be orange
Categories
(Release Engineering :: General, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: dbaron, Assigned: bhearsum)
Details
Attachments
(3 files)
681 bytes,
patch
|
nthomas
:
review+
bhearsum
:
checked-in+
|
Details | Diff | Splinter Review |
2.21 KB,
patch
|
catlee
:
review-
|
Details | Diff | Splinter Review |
3.19 KB,
patch
|
catlee
:
review+
bhearsum
:
checked-in+
|
Details | Diff | Splinter Review |
In at least some cases of test failure (crash/hang), the leak test boxes report a red build rather than an orange one. For an example, see http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1234378261.1234382132.15587.gz This should be reporting orange for test failure rather than red for build failure.
Assignee | ||
Comment 1•15 years ago
|
||
It looks like flunkOnFailure is defaulted to True for ShellCommands, which the AliveTest steps are a subclass of. Let's try flipping that and see if that helps. Patch incoming.
Assignee: nobody → bhearsum
Status: NEW → ASSIGNED
Priority: -- → P2
Comment 2•15 years ago
|
||
What happens if we don't stop when these steps fail ? Later steps rely on the logs they produce.
Assignee | ||
Comment 3•15 years ago
|
||
Attachment #361849 -
Flags: review?(nthomas)
Assignee | ||
Comment 4•15 years ago
|
||
(In reply to comment #2) > What happens if we don't stop when these steps fail ? Later steps rely on the > logs they produce. We won't be flipping haltOnFailure - we still want to stop. flunkOnFailure controls whether or not a BuildStep can turn the overall build red
Updated•15 years ago
|
Attachment #361849 -
Flags: review?(nthomas) → review+
Assignee | ||
Comment 5•15 years ago
|
||
Comment on attachment 361849 [details] [diff] [review] don't flunkOnFailure in AliveTest changeset: 190:4617dc0f2fe8
Attachment #361849 -
Flags: checked‑in+ checked‑in+
Assignee | ||
Comment 6•15 years ago
|
||
I just landed & kicked a new build - let's see what happens.
Assignee | ||
Comment 7•15 years ago
|
||
Yargh, this patch didn't fix it. I'll have a closer look tomorrow.
Assignee | ||
Comment 8•15 years ago
|
||
I'm not sure why the last patch didn't resolve the issue, the step certainly ends up with FAILURE as its' status, according to the log, and the warnOnFailure/flunkOnFailure settings should turn it orange....In any case, let's try explicitly passing flunkOnFailure and flunkOnWarnings=False to AliveTest, which will end up getting passed down to ShellCommand. Do class level attributes not override in Python? I think they have to since that's how ShellCommand overrides BuildStep's flunkOnFailure.....
Attachment #362008 -
Flags: review?(catlee)
Comment 9•15 years ago
|
||
Comment on attachment 362008 [details] [diff] [review] explicitly pass flunkOnFailure=False and flunkOnWarnings=False if haltOnFailure==True, then the step will be marked as FAILED in buildbot/process/base.py:507
Attachment #362008 -
Flags: review?(catlee) → review-
Assignee | ||
Comment 10•15 years ago
|
||
Just landed this upstream. We can back out my second patch after landing this. I *think* we can get this picked up right away by a reconfig.
Attachment #362219 -
Flags: review?(catlee)
Comment 11•15 years ago
|
||
Comment on attachment 362219 [details] [diff] [review] haltOnFailure should not imply flunkOnFailure Looks good, but I think we need a full restart to pick up this change since we don't reload the buildbot core on reconfig.
Attachment #362219 -
Flags: review?(catlee) → review+
Assignee | ||
Comment 12•15 years ago
|
||
You're right again Catlee. For some reason I thought by changes were in buildstep.py, not base.py. I don't want to do a downtime just for this, but it will ride along in the next one.
Assignee | ||
Comment 13•15 years ago
|
||
For posterity, the upstream bug is http://buildbot.net/trac/ticket/425
Assignee | ||
Comment 14•15 years ago
|
||
Comment on attachment 362219 [details] [diff] [review] haltOnFailure should not imply flunkOnFailure changeset: 10:a2845f74d55d
Attachment #362219 -
Flags: checked‑in+ checked‑in+
Assignee | ||
Comment 15•15 years ago
|
||
This landed in production.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•