Building an R Project

What This Guide Covers

This guide covers build environment and configuration topics specific to R projects. Please make sure to read our Getting Started and general build configuration guides first.

Community-Supported Warning

Travis CI support for R is contributed by the community and may be removed or altered at any time. If you run into any problems, please report them in the Travis CI issue tracker and cc @craigcitro and @jimhester.

Basic configuration

R support in Travis CI is designed to make it easy to test R packages. If your R package doesn’t need any system dependencies beyond those specified in your DESCRIPTION file, your .travis.yml can simply be

language: r

Using the package cache to store R package dependencies can significantly speed up build times and is recommended for most builds.

language: r
cache: packages

If you do not see

This job is running on container-based infrastructure, which does not allow use of
'sudo', setuid and setguid executables.

You will need to set sudo: false in order to use the container based builds and package caching.

The R environment comes with LaTeX and pandoc pre-installed, making it easier to use packages like RMarkdown or knitr

Configuration options

Travis CI supports a number of configuration options for your R package.

R Versions

Travis CI supports R versions 3.1.3 and above on Linux Precise builds. Aliases exist for each major release, e.g 3.1 points to 3.1.3. In addition the name oldrel is aliased to 3.2.5 and release is aliased to 3.3.0. devel is built off of the R git mirror of the R SVN trunk (updated hourly).

Matrix builds are supported for R builds, however both instances of r must be in lowercase.

language: r
  - oldrel
  - release
  - devel

As new minor versions are released, aliases will float and point to the most current minor release.

The exact R version used for each build is included in the ‘R session information’ fold within the build log.


By default, Travis CI will find all R packages listed as dependencies in your package’s DESCRIPTION file, and install them from CRAN. You can include dependencies on packages in development by listing them in the Remotes: field in your DESCRIPTION. See the Remotes Vignette for more information on using development remotes in your package.

Most of the time you should not need to specify any additional dependencies in your .travis.yml.

LaTeX/TexLive Packages

The included TexLive distribution contains only a limited set of default packages. If your vignettes require additional TexLive packages you can install them using tlmgr install in the before_install step.

language: r

  - tlmgr install index

The best way to figure out what packages you may need is to look at the packages listed in the LaTeX error message and search for them on CTAN. Packages often have a Contained in: field that indicates the package group you need to install.

If you don’t need LaTeX, tell Travis CI not to install it using latex: false.


The default pandoc version installed is 1.15.2. Alternative pandoc releases can be installed by setting the pandoc_version to the desired version.

language: r
pandoc_version: 1.16

If you don’t need Pandoc, tell Travis CI not to install it using pandoc: false.

APT packages

Use the APT addon to install APT packages on both container-based (sudo: false) and standard (sudo: required) infrastructures. The snippet below installs a prerequisite for the R package xml2:

      - libxml2-dev

Note that the APT package needs to be white-listed for this to work on container-based infrastructure. This option is ignored on non-Linux builds.

An alternative that works only on standard infrastructure (sudo: required) is the apt_packages field:

  - libxml2-dev

Package check options

You can use the following top-level options to control what options are used when building and checking your package:

  • warnings_are_errors: This option forces all WARNINGS from R CMD check to become build failures (default true). This is especially helpful when preparing your package for submission to CRAN, and is recommended for most packages. Set warnings_are_errors: false if you don’t want WARNINGS to fail the build.

  • r_build_args: additional arguments to pass to R CMD build, as a single string. Defaults to empty.

  • r_check_args: additional arguments to pass to R CMD check, as a single string. Defaults to --as-cran.


A typical Bioconductor package should only need to specify the Bioconductor version they want to test against in their .travis.yml.

language: r
r: bioc-devel

Or if you want to test against the release branch

language: r
r: bioc-release

Travis CI will use the proper R version for that version of Bioconductor and configure Bioconductor appropriately for installing dependencies.


If you want Travis CI to use your project-specific packrat package library, rather than the default behaviour of downloading your package dependencies from CRAN, you can add this to your .travis.yml:

  - R -e "0" --args --bootstrap-packrat

You can minimise build times by caching your packrat packages with:

    - $TRAVIS_BUILD_DIR/packrat/src
    - $TRAVIS_BUILD_DIR/packrat/lib
  packages: true


  • cran: CRAN mirror to use for fetching packages. Defaults to

  • repos: Dictionary of repositories to pass to options(repos). If CRAN is not given in the dictionary the value of the cran option is used. Example:

  • disable_homebrew: if true this removes the preinstalled homebrew installation on OS X. Useful to test if the package builds on a vanilla OS X machine, such as the CRAN mac builder.

Environment Variables

R-Travis sets the following additional environment variables from the Travis defaults.

  • TRAVIS_R_VERSION=3.2.4 Set to version chosen by r:.
  • R_LIBS_USER=~/R/Library
  • R_LIBS_SITE=/usr/local/lib/R/site-library:/usr/lib/R/site-library
  • NOT_CRAN=true
  • R_PROFILE=~/

Additional Dependency Fields

For most packages you should not need to specify any additional dependencies in your .travis.yml. However for rare cases the following fields are supported.

Each of the names below is a list of packages you can optionally specify as a top-level entry in your .travis.yml; entries in these lists will be installed before building and testing your package. Note that these lists are processed in order, so entries can depend on dependencies in a previous list.

  • apt_packages: See above

  • brew_packages: A list of packages to install via brew. This option is ignored on non-OS X builds.

  • r_binary_packages: A list of R packages to install as binary packages on linux builds, via Michael Rutter’s cran2deb4ubuntu PPA. These installs will be faster than source installs, but may not always be the most recent version. Specify the name just as you would when installing from CRAN. On OS X builds and builds without sudo: required, these packages are installed from source.

  • r_packages: A list of R packages to install via install.packages.

  • bioc_packages: A list of Bioconductor packages to install.

  • r_github_packages: A list of packages to install directly from GitHub, using devtools::install_github from the devtools package. The package names here should be of the form user/repo. If the package is installed in a subdirectory, use user/repo/subdirectory. An alternative is to add user/repo or user/repo/folder to the Remotes section of the DESCRIPTION file of your package

Customizing the Travis build steps

For some advanced use cases, it makes sense to override the default steps used for building R packages. The default rules roughly amount to:

- R -e 'devtools::install_deps(dep = T)'

- R CMD build .
- R CMD check *tar.gz

If you’d like to see the full details, see the source code.


If you are using the container based builds you can take advantage of the package cache to speed up subsequent build times. For most projects these two lines are sufficient.

language: r
cache: packages

Package in a subdirectory

If your package is in a subdirectory of the repository you simply need to change to the subdirectory prior to running the install or script steps.

language: r
  - cd subdirectory

Remote package

If your package depends on another repository you can use r_github_packages in this way:

r_github_packages: user/repo

An alternative is to add the following line to your DESCRIPTION file:

Imports: pkg-name-of-repo
Remotes: user/repo

Remember that Remotes: specifies the source of a development package, so the package still needs to be listed in Imports:, Suggests: Depends: or LinkingTo:. In the rare case where repo and package name differ, Remotes: expects the reposistory name and Imports: expects the package name (as per the DESCRIPTION of that imported package).

Remote package in a subdirectory

If your package depends on another repository which holds the package in a subdirectory, you can use r_github_packages in this way:

r_github_packages: user/repo/folder

An alternative is to add the following line to your DESCRIPTION file:

Remotes: user/repo/folder

Converting from r-travis

If you’ve already been using r-travis to test your R package, you’re encouraged to switch to using the native support described here. We’ve written a porting guide to help you modify your .travis.yml.


R support for Travis CI was originally based on the r-travis project, and thanks are due to all the contributors. For more information on moving from r-travis to native support, see the porting guide.