sbt hangs during tests on travis-ci

Viewed 773

I have an open source scala project (https://github.com/lucidsoftware/xtract). The build on travis-ci consistently hangs while running tests, for both scala 2.11 and 2.12. Sometimes it hangs after compiling and before any output from tests, other times it hangs in the middle of running tests. I have tried several iterations of changing the travis, inclding trying with and without sudo: false, different versions of sbt, splitting up the sbt commands in different ways, using both oraclejdk8 and openjdk8, etc.

Am I doing something wrong or is this a bug?

Sample failure: https://travis-ci.org/lucidsoftware/xtract/jobs/280974227

My .travis.yml:

language: scala

scala:
  - 2.11.11
  - 2.12.3

jdk:
  - openjdk8

dist: trusty
sudo: false

cache:
  directories:
    - $HOME/.ivy2/cache
    - $HOME/.sbt/

after_success:
  - sbt ++$TRAVIS_SCALA_VERSION package
  - |
    if [ -n "$TRAVIS_TAG" ] || ([ "$TRAVIS_PULL_REQUEST" == false ] && [ "$TRAVIS_BRANCH" == master ])
    then
      mkdir ~/.pgp
      echo $PGP_PUBLIC | base64 --decode > ~/.pgp/pubring
      echo $PGP_SECRET | base64 --decode > ~/.pgp/secring
      echo "Publishing snapshot"
      sbt ++$TRAVIS_SCALA_VERSION xtract/publishSigned xtractTesting/publishSigned
    fi
deploy:
  api_key: $GITHUB_AUTH
  file:
    - xtract-core/target/**/*.jar
    - testing/target/**/*.jar
  file_glob: true
  provider: releases
  skip_cleanup: true
  on:
    tags: true

install: sbt ++$TRAVIS_SCALA_VERSION update
before_cache:
  #Avoid unncessary cache updates
  - find $HOME/.ivy2 -name "ivydata-*.properties" -print -delete
  - find $HOME/.sbt  -name "*.lock" -print -delete

EDIT

Failure with -debug option on sbt: https://travis-ci.org/lucidsoftware/xtract/jobs/281081862

The last thing it does is

[debug] Running TaskDef(com.lucidchart.open.xtract.DefaultXmlReadersSpec, specs2 Specification fingerprint, false, [SuiteSelector])

Edit 2

Some notes. This project has multiple subprojects. The build pauses while running tests, and the test are in their own project, because they depend on both the core code, and an a separate sub-project for specs2 matchers specific to the project.

3 Answers
Related