
Travis-Pls: Travis Builds That Don't Timeout - naftulikay
https://github.com/naftulikay/travis-pls
======
urda
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.

~~~
Xylakant
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.

~~~
empath75
Ami building produces output.

------
thedaniel
Why so mean? [https://github.com/naftulikay/travis-
pls/pull/2](https://github.com/naftulikay/travis-pls/pull/2)

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

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

~~~
mintplant
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.

~~~
Sir_Substance
>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.

------
fluxsauce
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
I use this script:

    
    
      #!/bin/bash
      set -eu
    
      (while sleep 60; do echo Do not kill me yet!; done) &
      "$@"

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

------
manojlds
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
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

