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.
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.
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
urda|9 years ago
No, stop, and get this garbage out of here.
michaelmior|9 years ago
Xylakant|9 years ago
However, never timing out stuck builds clearly is an issue, so I filed a ticket for it.
thedaniel|9 years ago
johmue|9 years ago
Operyl|9 years ago
xgbi|9 years ago
mintplant|9 years ago
fluxsauce|9 years ago
gregwebs|9 years ago
libeclipse|9 years ago
manojlds|9 years ago
manacit|9 years ago
There's no need to be a dick about it though, which seems to be the centerpiece of this