Back to 11/30, I reach a conclusion: even using Docker to test R package can figures out excatly what the package needs 1, it doesn’t worths the time needed to develop such an approach 2, unless Travis broken again.
Since yesterday, I began to organize my R package template.
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. 3
The biggest advantage is that it’s easier to have the same environment on remote & local. Good news are that I have already established how to use R Docker on Travis. 4
I can also separate install & test now, previously packages like
testthatwould 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. I learn it’s better to install all common system dependency 5, from the experience of from building bookdown in last week,
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.