Travis builds often timeout due to no build output

[56quarters]

Hi there,

I recently submitted a PR (gh-6588) but had the Travis CI tests fail initially (and a few times after that). There didn't appear to be any actual test failures, Travis had just aborted the build since it went more than 10 minutes without generating any output. Eventually I was able to get the tests to pass by opening and closing the PR to get Travis to rerun the tests. It would be great if this wasn't required. As such, I have a few questions about the current Travis configuration.

before_script:
- ./mvnw install -q -U -DskipTests=true -Dmaven.test.redirectTestOutputToFile=true || true
- ./mvnw install -q -U -DskipTests=true -Dmaven.test.redirectTestOutputToFile=true

1. Is there any reason the -q flag couldn't be removed? This would generate build output and Travis wouldn't kill the builds for running too long.
2. It seems like the same install command is run twice? I'm not sure why this is done. Perhaps to work around intermittent failures of the first command?

Would people like a PR to remove the -q flags and possibly the second call to ./mvnw install?

Thanks

[wilkinsona]

Is there any reason the -q flag couldn't be removed?

IIRC, without the -q flag, the build produces too much output and Travis kills it.

It seems like the same install command is run twice? I'm not sure why this is done. Perhaps to work around intermittent failures of the first command?

I'm not sure either, and looking at the history of the file hasn't made it much clearer. It looks like it was added as part of trying to get the Travis build to work a couple of years ago.

Would people like a PR to remove the -q flags and possibly the second call to ./mvnw install?

Yes, please. Given that Travis will build the PR, it sounds like an excellent way to experiment.

[philwebb]

Travis is a bit of a nightmare, I wish we just had a single CI solution.

To answer the specific questions:

Is there any reason the -q flag couldn't be removed?

If I remember correctly without -q the amount of log output overwhelmed Travis. This was some time ago so perhaps that's no longer the case.

it seems like the same install command is run twice? I'm not sure why this is done.

Me neither, and it seems to be me that did it in c47024c :)
I can only assume it was to try an protect against failures by brute forcing a second run.

[56quarters]

Thanks for the input. I'll submit a PR and we can see what happens. Worst case, Travis appears to have a travis_wait function that can be used to invoke long running things.

[spencergibb]

From the spring cloud perspective, our authoritative builds are on jenkins.spring.io (ie that's where we publish snapshots). PR's are starting to migrate to https://circleci.com since we have many travis problems that we don't know how to solve.