Why does this exist? Great, let's get some stuck builds going on a great platform like Travis instead of fixing your awful build process.

No, stop, and get this garbage out of here.

I can imagine some cases where this might be necessary. But giving the middle finger to Travis leaves a bad taste in my mouth. Especially since the free offering is so generous and the 10 minute restriction seems completely reasonable.

The use case mentioned in the readme seems perfectly reasonable and there is little that you can do to fix it. AMI building at AWS just takes time. The only party that could reasonably fix it is amazon. Travis provides the capability to extend build times as well but the function provided makes it hard to tell if the build process is actually running - so this seems like an improvement.

However, never timing out stuck builds clearly is an issue, so I filed a ticket for it.

Ami building produces output.

Why so mean? https://github.com/naftulikay/travis-pls/pull/2

so your flipping off the company that is testing opensource projects for free because your build process is wonky?

So, we're circumventing tools that kill possible stuck jobs now? That doesn't seem like it'll play out well with Travis CI...

Internally, we tend to call this kind of code, circumventing a procedure, the Volkswagen Code.

I thought that was where you add the following block to top of all the emissions^W unit tests:

    if (!regulators.areWatching()) {
        return;
    }

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.

I imagine that there's some other code in travis_wait to help deal with possibly stuck builds, though, shrug.

And well, it's not flipping off a company that does a lot for free to OSS.

I hear the frustration, but what about optimizing the build? Are there pieces that can be cached? What's the longest running part and why?

I use this script:

  #!/bin/bash
  set -eu

  (while sleep 60; do echo Do not kill me yet!; done) &
  "$@"

How about fixing your own build instead of exploiting a service that's doing your building and testing for you for FREE.

The use case mentioned in the README around Packer and building AMIs seems very valid to me. If Travis is fine with longer builds (they provide a way to avoid timeout) I don't see why everyone is pouring hate on this.

IMO, the idea of printing something to STDOUT every 9 minutes (or 5 minutes, or 1 minute, or whatever) is totally fine, and maybe this will even be helpful to someone.

There's no need to be a dick about it though, which seems to be the centerpiece of this