<HTML><BODY><div><div><div><div><div><div><div><div><div>> > after the patch we will use github runners and it is worth set a timeout<br>> > for jobs,<br>> ><br>> > otherwise we might run out of time on the runners (AFAIK it is limited<br>> > there).<div>></div>> Agree here. IINM, the default is 6 hours [1], which is too much for our<br>> tests.<br>> The longest job is Valgrind job, which is running about 12 minutes.<br>> I suppose the limit of 30 minutes is reasonable.<div>></div>> <snipped><div>></div><div>> [1]: <a href="https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idtimeout-minutes">https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idtimeout-minutes</a></div><div> </div><div>I agree that it is good to have job timeouts.</div><div> </div><div>I’d let the maintainers to set appropriate timeouts.</div><div>Personally, I neither use the jobs nor know details about them.</div><div>And I don’t think that it becomes more urgent when we switch</div><div>from 6 parallel runners to 60 (I’d say the opposite).</div><div> </div><div>WBR, Alexander Turenko</div></div></div></div></div></div></div></div></div></div></BODY></HTML>