By Randy Zwitch
No output has been received in the last 10m0s, this potentially indicates a
stalled build or something wrong with the build itself.
As part of getting RSiteCatalyst 1.4.8 ready for CRAN, I’ve managed to accumulate hundreds of testthat tests across 63 test files. Each of these tests runs on Travis CI against an authenticated API, and the API frequently queues long-running reports. Long-story-short, my builds started failing, creating the error log message quoted above.
Stalled Build?
The most frustrating about this error is that all my tests run (albeit, a looooong time) successfully through RStudio, so I wasn’t quite sure what the problem was with the Travis CI build. Travis CI does provide a comment about this in their documentation, but even then it didn’t solve my problem:
When a long running command or compile step regularly takes longer than 10 minutes without producing any output, you can adjust your build configuration to take that into consideration.
The shell environment in our build system provides a function that helps to work around that, at least for longer than 10 minutes.
If you have a command that doesn’t produce output for more than 10 minutes, you can prefix it with
travis_wait, a function that’s exported by our build environment.
The travis_wait command would work if I were installing packages, but my errors were during tests, so this parameter isn’t the answer. Luckily, testthat provides a test filtering mechanism, providing a solution by allowing the tests to be broken up into smaller chunks.
Regex To The Rescue…
For many applications, the default testthat configuration example will work just well:
R CMD check
Create tests/testthat.R that contains:
library(testthat)
library(yourpackage)
test_check("yourpackage")
However, hidden within the test_check() arguments is ‘filter’, which will take a regular expression to filter which files in the test folder will get run when the command is triggered by R CMD check. Why is this …read more
Source:: r-bloggers.com