pagespeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Marantz <>
Subject Re: system-test failure under valgrind
Date Fri, 13 Oct 2017 16:49:25 GMT
On Fri, Oct 13, 2017 at 12:00 PM, Otto van der Schaaf <>
> So one drawback is that if you run the mod_pagespeed tests from the
> ngx_pagespeed checkout, the mod_pagespeed git submodule will be pinned to a
> specific
> revision. (Which currently is not the head of mod_pagespeed's master
> branch.
> I'll create a PR to update this)
> Did you update the mod_pagespeed testing dependency to the tip of the
> branch
> before running the tests?

No.  Is there a best-practice flow for developing and iterating on PSOL
&/or mod_pagespeed?  I thought the general thinking is that we'd do this as
a dependency of ngx_pagespeed to make sure that in the flow we didn't wind
up breaking the latter, so that's what I did.

If we do a code migration to Apache's source control then it would be great
opportunity to unify under a single repo.

> I think it was a flake, the tests certainly are able to pass -- for
> example:
> 578b786e73282663024d4abfc65/ubuntu-1404-x64-checkin-test
> (Test run for
> 7df4578b786e73282663024d4abfc65
> )
> I do not remember seeing the test you posted fail before though.

One thing I want to remind everyone of listening is: if you are writing a
positive system-test for rewriting a resource, the best practice is to use
fetch_until rather just WGET and look at output.  This allows PageSpeed to
finish the rewrite even if the machine is slow.  Valgrind tests often tease
this out.

I just ran into this again on a second attempt on,
which I think was added recently.  I have a fix for that I'm testing now.


Yes that was what I was looking for!  Although it probably needs work to
help deal more sanely with flaky tests.  E.g. I'd like to be able to have
it go all the way through and tell me all the tests that failed, then give
me the opportunity to re-run just the failing ones while iterating.
Ideally this is a problem someone has already solved with some open-source
test script infrastructure we could just use.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message