On Fri, Oct 13, 2017 at 12:00 PM, Otto van der Schaaf <[email protected]> wrote: > > 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: > http://ci.onpagespeed.com/stream/mod_pagespeed/6203400cd7df4 > 578b786e73282663024d4abfc65/ubuntu-1404-x64-checkin-test > (Test run for > https://github.com/pagespeed/mod_pagespeed/commits/6203400cd > 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 css_minify_calc_function_value_zero.sh, which I think was added recently. I have a fix for that I'm testing now. > https://github.com/pagespeed/mod_pagespeed/blob/master/devel/checkin 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.
