Travis CI themselves offer a workaround for their own timeout in the form of travis_wait. This seems to be a slightly different alternative workaround that better meets the authors' needs.
>This seems to be a slightly different alternative workaround that better meets the authors' needs
You can take an educated guess though that the fact that travis_wait doesn't keep streaming the output is probably deliberate.
I've been on the other end of the stick often enough. You put in place mechanisms that are designed to protect your system from over-burdensome use and gently prod people towards better ways of using it. Most people take a hint and solve the underlying problem, but some people instead choose to dodgily bypass the protective measures in front of your free system.
Inevitably, you have to send them a mail saying "I can see you on the graphs, stop what you're doing". They try to take it as an opportunity to "open a dialogue" about the problem, and then get in a huff when you respond with "I don't care right now, I've already asked you nicely once, you have one hour to stop using 10% of all our memory, and then you're getting perma-banned".
Anyone with half a brain can take a guess that the travis_wait behavior is probably a defense against really verbose and long builds gumming up their system with millions of lines of stdout that no one cares about. Having the need to bypass it suggests you're operating in a fashion where you really ought to be running your own build system (or breaking up your build process into a clean, sectioned pipeline with parallel test execution), rather than using shared resources.
