<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 9, 2015 at 11:49 AM, Poul-Henning Kamp <span dir="ltr"><<a href="mailto:phk@phk.freebsd.dk" target="_blank">phk@phk.freebsd.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">--------<br>
In message <CAOXZevCbv95KkamMUb=<a href="mailto:LPezgP0jO%2BNjn%2BNbP5-VBTBwpTuif3g@mail.gmail.com">LPezgP0jO+Njn+NbP5-VBTBwpTuif3g@mail.gmail.com</a>><br>
<span class="">, Per Buer writes:<br>
<br>
>Intermittently failing tests seems to be an issue.<br>
<br>
</span>Yes, indeed.<br>
<br>
But the one thing I would *really* like to get is some kind of statistics<br>
of *which* test-cases we have this problem with, and I wish Jenkins could<br>
somehow be persuaded to collect such info.<br></blockquote><div><br></div><div>That was the main objective. </div><div><br></div><div>Having the testrunner have an optional interface to something like a database would be trivial.  Having something that is able to collect a bit of context to a testrun in a database (load, IO response, etc) would be helpful in order to figure out _why_ certain tests are failing on certain platforms.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
>Another option would be to start giving hints on how the test should be<br>
>executed within the test itself. By having a header on the test that the<br>
>testrunner could read one can set up certain parameters.<br>
><br>
># parallel=0,load<1,timeout=15s,platforms=!netbsd,retries=3<br>
<br>
</span>I'm not very keen on this, it is an open invitation to not take<br>
the battle and fix the test-cases properly.<br>
<br>
(With respect to "platforms=!netbsd" we already have a "feature"<br>
keyword, that looks for specific details in the run-environment.)<br></blockquote><div><br></div><div>Sure. I'm not at all convinced it is a good idea, it is just an option available to us if we have a somewhat more sophisticated tool to schedule tests than what autocrap gives us.</div><div><br></div><div>We can of course our own threshold for what we deem an acceptable configuration of a test. If tests that are unable to finish on a loaded system or a system without apriori knowledge of how the IO response is are not acceptable than we shouldn't accept those tests.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
>Let me know if I should commit this and start replacement of the current<br>
>way tests are run.<br>
<br>
</span>So my first question is:  Why don't we just teach varnishtest to do this ?<br></blockquote><div><br></div><div>Because scheduling the tests and running the tests are different tasks. Scheduling and interfacing with a database is pretty trivial in Python and not something we should do directly in the varnishtest itself.</div><div><br></div><div>The ultimate goal here is to be able to produce reports on how the various tests are doing. What tests are timing sensitive and what platforms they seem to be struggling. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It would be really trivial to make varnishtest collect the failing<br>
tests on a list and then run that list after the main-run in<br>
single-threaded mode (enabled by some argv)<br></blockquote><div><br></div><div>Absolutely. And that is what the proposed solution does. It allows us to keep varnishtest a relativly simple program that deal with running a single test and it delegates the scheduling role to something else (not autotools). And it does it without introducing any new dependencies (we already are dependant on Python for building and I haven't used any modules outside the core, AFAIK).</div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><table border="0" cellpadding="0" cellspacing="0" style="border-bottom-width:1px;padding-top:5px;border-top-style:solid;width:550px;padding-bottom:5px;border-bottom-color:rgb(238,238,238);border-top-width:1px;border-bottom-style:solid;line-height:1.5em;border-top-color:rgb(238,238,238);color:rgb(102,102,102);font-size:12px;font-family:'Helvetica Neue',Arial,sans-serif;margin-top:20px"><tbody><tr><td width="100"><img src="http://www.varnish-software.com/static/media/logo-email.png"></td><td><font color="#222222"><span style="font-size:14px"><b>Per Buer</b></span></font><br>CTO | Varnish Software AS<br>Cell: <a value="+4790181750" style="color:rgb(17,85,204)">+47 95839117</a><br><span style="font-weight:bold">We Make Websites Fly!<br><a href="https://www.varnish-software.com/" style="color:rgb(17,85,204)" target="_blank">www.varnish-software.com</a></span></td></tr></tbody></table><br><div style="color:rgb(136,136,136)"><a href="http://info.varnish-software.com/varnish-summits-autumn-2014-registration" style="color:rgb(17,85,204)" target="_blank"><img src="https://www.varnish-software.com/sites/default/files/u388/masters_s_0.png" alt=" Register now"></a></div></div></div>
</div></div>