travis builds time out -- then keep restarting ???

[Mojca Miklavec]

On 2 January 2018 at 23:28, Jan Stary wrote:
> On Jan 02 22:20:25, raimue at 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