Ah, I misunderstood.
If the log line is printed or dumped directly to stdout, then the string
TEST-UNEXPECTED-FAIL actually will fail the job. It's only if we do
log.info('TEST-UNEXPECTED-FAIL ...') that we run into problems. So if
you see the string 'TEST-UNEXPECTED-FAIL' somewhere, it isn't
Also note this has happened before. mccr8 was looking into similar
leak-checking-is-totally-busted-but-nobody-noticed issues a few years ago
in https://bugzilla.mozilla.org/show_bug.cgi?id=1045316
Glad to hear you're looking into end-to-end tests!
-e
On Thu, Dec 29, 2016 at 8:37 AM, Andrew
On 12/29/16 11:49 AM, ahalberst...@mozilla.com wrote:
Have we done any sort of audit to see whether any other tests got broken
by the structured logging changes? Had we done such an audit after bug
1321127 was fixed?
Once bug 1321127 was fixed, any other tests that were broken would turn the
On Thursday, December 29, 2016 at 2:04:28 PM UTC-5, Boris Zbarsky wrote:
> Andrew, thank you for catching this! This sounds a _lot_ like
> https://bugzilla.mozilla.org/show_bug.cgi?id=1321127 in terms of cause
> and effects.
Yes, that bug is a similar failure. In both cases we should have had
On 12/29/16 8:37 AM, Andrew Halberstadt wrote:
Over the holidays, we noticed that leaks in mochitest and reftest were
not turning jobs orange, and that the test harnesses had been running in
that state for quite some time. During this time several leak related
test failures have landed, which
Over the holidays, we noticed that leaks in mochitest and reftest were
not turning jobs orange, and that the test harnesses had been running in
that state for quite some time. During this time several leak related
test failures have landed, which can be tracked with this dependency tree:
6 matches
Mail list logo
