On 2 January 2018 at 23:28, Jan Stary wrote: > On Jan 02 22:20:25, rai...@macports.org wrote: >> On 01/02/2018 11:13 AM, Jan Stary wrote: >> >> > It is still happening, see e.g. >> > https://github.com/macports/macports-ports/pull/1186 >> >> This looks like a normal timeout. >> The build finished and I see no restarts. > > Maybe I just don;t get the Travis terminology, > but it smultaneously finished _and_ timed out?
No, it just timed out and was forcibly shut down. What Rainer meant with "finished" was that the job no longer runs, whatever the reason was for stopping it. >> The timeout after 50 minutes is expected. >> This is a limitation of Travis CI and cannot be increased. > > Why? Surely it's a config constant. Yes, it probably is. Except that you need to pay subsription to increase that constant to 120 minutes which still won't guarantee you any success: https://docs.travis-ci.com/user/customizing-the-build/#Build-Timeouts or maybe talk to them and explain them that you are willing to pay even more to get even longer timeouts. >> Pull requests for ports that need longer to build >> cannot be tested automatically. > > So what should I do about e.g. > https://github.com/macports/macports-ports/pull/1189 > which needs longer to build because it touches lirc? Probably nothing, at least nothing about that particular build. What you could do is: - implement a buildbot-based (or any other opensource-based) solution which can run arbitrarily long on our own hardware; the bigges problem is making it safe i.e. immune to arbitrary pull requests which could modify the machine (the machine would have to get back to its initial state after the PR gets processed) - a lot of timeout issues could be prevented if we had a way to fetch binary archives of binary non-distributable archives (that still wouldn't help ports that simply need a lot of time to build themselves, but it would help ports which have a non-distributable dependency) - file an issue with Travis which would deliver a different status, making it explicit that the job stopped with a timeout rather than a proper failure - or at least implement an improvement for our own setup which would automatically add a label "timeout" to the PR, making it evident that the failure in Travis is not due to a genuine error, but due to timeout > Currently, such PRs seem kinda discriminated with > "All checks have failed" (sounds horrible, right?) Some months ago we didn't have any Travis builds, so no "failed checks". I believe it's a personal taste what one considers more horrible :) Mojca