Devtools - Error in match.arg(upgrade, c("ask", "always", "never")) : 'arg' must be of length 1

As of the April 4th CRAN update to devtools v2.0.2, Travis CI is encountering an error with devtools during its setup phrase when building R packages (the error occurs prior to Travis testing any of the user’s R code). I’ve encountered this issue with a R package today that previously passed Travis’ tests - neither package’s code was changed before running on Travis.

Error in match.arg(upgrade, c("ask", "always", "never")) : 'arg' must be of length 1

See full Travis’s job log hope it helps!

3 Likes

I’ve faced the same problem since this morning, here is the log, how can we solve this problem?

1 Like

Chiming in on this, having the exact same error. Two package builds are currently failing due to this.

1 Like

I have the same issue too Log

1 Like

Same issue today with my last push… log

1 Like

Same story: link to log

1 Like

Same here.

1 Like

I tried this patch but it didn’t work…

r_github_packages:
  - r-lib/devtools

This is due to an inconsistency between devtools and the released version of the remotes package. I am planning on submitting a quick fix of remotes today to fix the issue. In the meantime you can install the development version of remotes to fix the issue in before_install.

before_install: R -e 'source("https://install-github.me/r-lib/remotes")'
3 Likes

I got another error now
The command "R -e 'source("https://install-github.me/r-lib/remotes")’" failed and exited with 1 during
log

1 Like

Same new error log

> source("https://install-github.me/r-lib/remotes")

Error in utils::download.file(url, path, method = download_method(), quiet = quiet, :

cannot open URL 'https://api.github.com/repos/r-lib/remotes/commits/master'

Calls: source ... remote_sha.github_remote -> github_commit -> download -> base_download

Execution halted

The command "R -e 'source("https://install-github.me/r-lib/remotes")'" failed and exited with 1 during .
1 Like

In my case this fixed the problem, thanks!

In my case just re-running the job did the trick, since the remotes version fixing this problem was already on CRAN. Thanks @jimhester!