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)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dbaron, Assigned: bhearsum)

Details

Attachments

(3 files)

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.
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
What happens if we don't stop when these steps fail ? Later steps rely on the logs they produce.
Attachment #361849 - Flags: review?(nthomas)
(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
Attachment #361849 - Flags: review?(nthomas) → review+
Comment on attachment 361849 [details] [diff] [review]
don't flunkOnFailure in AliveTest

changeset:   190:4617dc0f2fe8
Attachment #361849 - Flags: checked‑in+ checked‑in+
I just landed & kicked a new build - let's see what happens.
Yargh, this patch didn't fix it. I'll have a closer look tomorrow.
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 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-
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 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+
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.
For posterity, the upstream bug is http://buildbot.net/trac/ticket/425
Comment on attachment 362219 [details] [diff] [review]
haltOnFailure should not imply flunkOnFailure

changeset:   10:a2845f74d55d
Attachment #362219 - Flags: checked‑in+ checked‑in+
This landed in production.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: