<div dir="ltr">Looks like there might still be some issues with the timeout tests? <a href="http://lab.llvm.org:8011/#/builders/126/builds/226/steps/13/logs/FAIL__lit___shtest-timeout_py">http://lab.llvm.org:8011/#/builders/126/builds/226/steps/13/logs/FAIL__lit___shtest-timeout_py</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 4, 2020 at 2:44 PM Dan Liew <<a href="mailto:dan@su-root.co.uk">dan@su-root.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> > One thing we could do to remove fragility in the test is to remove the<br>
> > running of `short.py` in the test. This is only invoked to check that<br>
> > it's possible for a command to run to completion in the presence of a<br>
> > fixed timeout. If we can live without testing that part (i.e. we only<br>
> > test that a timeout can be reached) then the test should be much more<br>
> > robust.<br>
><br>
> If you're on board with that, it's a tradeoff I think is probably<br>
> reasonable from a test coverage V reliability V development time<br>
> tradeoff.<br>
<br>
Sorry for the delay here. I've put a patch up for review that goes<br>
with this approach: <a href="https://reviews.llvm.org/D88807" rel="noreferrer" target="_blank">https://reviews.llvm.org/D88807</a><br>
</blockquote></div>