Skip to Content

Use Docker to test R packages on Travis


Back to 11/30, I reach a conclusion: although using Docker to test R package can figures out excatly1 what the package needs. it doesn’t worths the time needed to develop such an approach, unless Travis broken again. (Travis 现成的 R 环境多好啊,还支持 OS X 和多个 R 版本)


Since yesterday, I began to organize my R package template.


I add devtools to Suggests, then Travis CI failed. After debug, it says some packages are not available for R 3.5.1. That was very strange, since I use that version on my own computer.

After several trail, I got tried and decided to give up. I realized that debugging R on Travis is so annoying and time-consuming, so I’d better switch to Docker (真香).


  • The biggest advantage is that it’s easier to have the same environment on remote & local. Good news is that I have already established how to use R Docker on Travis. Bad news is the need to cache R packages.

  • I can also separate install & test now, previously packages like testthat would interfere the install setp (unless cache has been clean). Although a single R version needs two jobs now.

  • Even more, I find using Docker is considerable faster: previous ~4m * 3, now ~2m * 3.

As for investiging excat dependency, forget about it. From the experience of from building bookdown in last week, I learn it’s better to install all common system dependency rather than debugging tons of times for each package.


Next morning, I tried using build stage, but find it not appropriate. Since the two jobs contain common install step, switch to build stage would need to repeat those 4 lines of code.

  1. including but not limited to system softwares, such as libssl-dev↩︎