top | item 13817344

Travis-Pls: Travis Builds That Don't Timeout

39 points| naftulikay | 9 years ago |github.com

17 comments

order

urda|9 years ago

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.

michaelmior|9 years ago

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.

Xylakant|9 years ago

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.

johmue|9 years ago

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

Operyl|9 years ago

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

xgbi|9 years ago

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

mintplant|9 years ago

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.

fluxsauce|9 years ago

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?

gregwebs|9 years ago

I use this script:

  #!/bin/bash
  set -eu

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

libeclipse|9 years ago

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

manojlds|9 years ago

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.

manacit|9 years ago

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