Long-running travis testing

Package Development
1

I’m running into a problem where my package Check take a long time and Travis times out with the error:

Running ‘testthat.R’

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received

That documentation talks about including a term travis_wait, but since the Check happens automatically, I’m not sure how to use that feature. Here’s what I tried, but it seemed to just allow the “wait” on opening R the first time:

language: r
cache: packages
sudo: false
dist: trusty

matrix:
  include:
    - os: linux
      r: release
    - os: linux
      r: devel

addons:
  apt:
    packages:
    - libcurl4-openssl-dev

env:
   global:
     - R_BUILD_ARGS="--no-build-vignettes --no-manual"
     - R_CHECK_ARGS="--no-build-vignettes --no-manual --as-cran"
     - NOT_CRAN="true"
     - _R_CHECK_FORCE_SUGGESTS_=false
     
warnings_are_errors: true

install:
  - travis_wait 30 Rscript -e "0" 

r_github_packages:
  - jimhester/covr

after_success:
  - Rscript -e 'covr::coveralls()'
  
notifications:
  email:
    on_success: change
    on_failure: change

Has anyone used the travis_wait function on a native R build?

2

Good question @ldecicco-USGS

I’ve not played with travis_wait (for reference, https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received)

@jimhester may know?

3

See https://github.com/travis-ci/travis-ci/issues/3849#issuecomment-255096774 for how to use travis_wait to override the script: step. However most of the time the build is hanging due to a bug in the package, often because it assumes there is a open display device (which is not the case on Travis). So make sure that R CMD build . && R CMD check *tar.gz works locally and be very sure that your build is not just hanging waiting for a resource it will never get before trying to use travis_wait.

1 Like
4

Super, thanks! That’s exactly the conversation I needed to find. I legitimately have a very looong set of tests. Sometimes they finish just under the 10 minute mark, but usually they take a bit longer. It’s all set to “testthat::skip_on_cran()”, but those are especially the ones I’d like Travis to run.