Tweak travis_wait

[BanzaiMan]

Instead of redirecting I/O and sending commands passed to the background, we simply start a job which write audio bells every 60 seconds or so to STDOUT, so that the job we want to live long does not get killed.

[BanzaiMan]

A simple test is found here: https://staging.travis-ci.org/BanzaiMan/travis_staging_test/builds/547416

[BanzaiMan]

Some GitHub issues that may benefit from this PR:

travis-ci/travis-ci#5281
travis-ci/travis-ci#5716
travis-ci/travis-ci#6934
travis-ci/travis-ci#7052
travis-ci/travis-ci#7323

[solarce]

What's the risk of this resulting in users hitting the 4mb log limit, if those users are counting on the existing travis_wait behavior of suppressing all output?

Could this behavior be made optional at first?

[BanzaiMan]

@solarce That is a valid point. The risk is there. We will do well to make this less intrusive.

[meatballhat]

If I understand correctly, this change in behavior will mean that even if the command returns immediately, there will be a visual bell written to output every 60s. Is that acceptable? Given the amount of ANSI code noise in our archived logs, I tend to think it's hardly going to be noticed.

[domenkozar]

While I haven't tested this solution, we did hit the quoting bug as well. Using travis_wait 20 sleep 4600& as a workaround

[abitrolly]

So, what is required to merge this?

[calvn]

@BanzaiMan any update as to when/if this will be merged? It'd be very useful to have output get streamed as the build is ran, rather than wait for travis_wait to timeout or exit on error.

[BanzaiMan]

I'm going to revert this for now, in light of travis-ci/travis-ci#9663.