krlmlr/r-appveyor

../travis-tool.sh: line 163: Rscript: command not found

HenrikBengtsson opened this issue · 2 comments

PROBLEM:
I forked r-appveyor "as-is" as but my AppVayor build complaints that Rscript cannot be found:

git clone -q --branch=master git://github.com/HenrikBengtsson/r-appveyor.git C:\projects\r-appveyor
git checkout -qf 787ee3ead5ca02f61b4aa44494f4a9326f5c1393
...
+ Rscript -e 'install.packages(commandArgs(TRUE), repos="http://cran.rstudio.com")' devtools testthat
../travis-tool.sh: line 163: Rscript: command not found
Command exited with code 127

Full details: https://ci.appveyor.com/project/HenrikBengtsson/r-appveyor/build/1.0.2

This is exact same checkout of r-appveyor as you're running:

git clone -q --branch=master git://github.com/krlmlr/r-appveyor.git C:\projects\r-appveyor
git checkout -qf 787ee3ead5ca02f61b4aa44494f4a9326f5c1393
...
+ Rscript -e 'if (!("devtools" %in% rownames(installed.packages()))) q(status=1)'
+ Rscript -e 'library(devtools); library(methods); options(repos=c(CRAN="http://cran.rstudio.com")); install_deps(dependencies = TRUE)'
Installing dependencies for fakepackage:

Full details: https://ci.appveyor.com/project/krlmlr/r-appveyor/build/1.0.455

SOME TROUBLESHOOING:
To check if 'R' (the binary) is even found, I've added

build_script:
  - travis-tool.sh dump_sysinfo
  - travis-tool.sh install_deps 

which gives:

Dumping system information.
+ R -e '.libPaths(); sessionInfo(); installed.packages()'
../travis-tool.sh: line 215: R: command not found
Command exited with code 127

Full details: https://ci.appveyor.com/project/HenrikBengtsson/r-appveyor/build/1.0.3

Any suggestions? Did I miss something obvious?

Thanks for reporting. This is strange to me.

Installing R works by downloading a .vhd file and mounting it. The mount process takes roughly 40 seconds in my build, but just 5 seconds in your build. I wonder if mounting succeeds at all.

Could you please add something like dir e: to your configuration to troubleshoot this further? The .vhd is usually mounted as drive E, but this could be different for some reason in your builds, so it could be worthwhile to check also other drives.

Yes, the hard-coded assumption that R is mounted on E: was the problem. I've created pull request #27 that quickly scans for the correct drive.