Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[travis] Avoiding build timeouts #2820

Merged
merged 8 commits into from May 5, 2019

Conversation

Projects
None yet
2 participants
@jimschubert
Copy link
Member

commented May 4, 2019

PR checklist

  • Read the contribution guidelines.
  • Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
  • Filed the PR against the correct branch: master, 3.4.x, 4.0.x. Default: master.
  • Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

Description of the PR

Travis CI will timeout if there is no activity printed to stdout or
stderr for 10 minutes. Running our mvn commands with --quiet option may
hit this limit for any number of reasons (more code, network
conditions). To avoid this, we remove --quiet and adjust some other
Maven configuration options.

One, specifically, is the cached .m2/repository directory. We bind this
to a non-user home location due to the -u binding found in
run-in-docker.sh. We then provide a settings.xml and CLI option to tell
maven where to look for our cached repository directory. This should
allow both users and CI to run the script in a consistent way, but most
importantly should allow Travis to continue to cache artifacts across
builds.

[travis] Avoiding build timeouts
Travis CI will timeout if there is no activity printed to stdout or
stderr for 10 minutes. Running our mvn commands with --quiet option may
hit this limit for any number of reasons (more code, network
conditions). To avoid this, we remove --quiet and adjust some other
Maven configuration options.

One, specifically, is the cached .m2/repository directory. We bind this
to a non-user home location due to the -u binding found in
run-in-docker.sh. We then provide a settings.xml and CLI option to tell
maven where to look for our cached repository directory. This should
allow both users and CI to run the script in a consistent way, but most
importantly should allow Travis to continue to cache artifacts across
builds.
@jimschubert

This comment has been minimized.

Copy link
Member Author

commented May 4, 2019

@wing328

This comment has been minimized.

jimschubert added some commits May 5, 2019

Merge branch 'master' into travis-timeout-fixes
* master:
  resize lightbow logo
  add lightbow logo
  add Lightbow as sponsor (#2822)
  [docs] Document new templating engine, adding ability to reference templates by file to comlete the example (#2773)
  [JAVA][KOTLIN] fix var Naming for all uppercase with Numbers (#2794)
  [Documentation] Add instructions to build the javascript client module (#2806)
  use mvn instead of run-in-docker (#2821)
  Better handling of form data (#2818)
  [haskell-servant] Add some missing types to the generated modules (#2675)
@jimschubert

This comment has been minimized.

Copy link
Member Author

commented May 5, 2019

Summarizing discussion from chat here…

We were using run-in-docker.sh to integrate a sort of evaluation of that script into the build. While evaluating the script locally, I found that the .m2 repository in container wasn't setup properly for a user-bound volume. This may have been causing the dockerized build in Travis to hit the 10 minute timeout limit. This is hard to juggle with the --quiet option, because that option is intended to only display errors but Travis will kill the build if no stdout/stderr is written out for 10 minutes. Also, running locally I found that "Scanning for projects" sometimes took longer to succeed than it should (and this is where many Travis CI builds would freeze).

The option I've taken in this PR is to provide some options for CI which will limit some logs (Slf4jMavenTransferListener=WARN) while still outputting mvn output without --quiet. This also introduces MAVEN_CLI_OPTS which is to be passed to mvn directly with options to hopefully make evaluating Maven build output easy to reason about.

jimschubert added some commits May 5, 2019

Remove multi-threading (org.fortasoft:gradle-maven-plugin is not thre…
…ad-safe), and use travis_wait 20 on mvn clean install

@jimschubert jimschubert force-pushed the travis-timeout-fixes branch from 6a26c19 to 76d540d May 5, 2019

@jimschubert

This comment has been minimized.

Copy link
Member Author

commented May 5, 2019

Travis builds have succeeded, and others are unaffected by these changes, so I'll go ahead and merge this.

@jimschubert jimschubert merged commit 26d0487 into master May 5, 2019

2 of 6 checks passed

Shippable Run 7745 status is WAITING.
Details
ci/circleci Your tests are queued behind your running builds
Details
continuous-integration/appveyor/branch Waiting for AppVeyor build to complete
Details
continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@jimschubert jimschubert deleted the travis-timeout-fixes branch May 5, 2019

@jimschubert

This comment has been minimized.

Copy link
Member Author

commented May 5, 2019

work was also done in #2821 to remove run-in-docker.sh

@wing328 wing328 added this to the 4.0.0 milestone May 9, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.