Chapter 2 Continuous Integration Best Practices
This chapter summarizes our guidelines about continuous integration after explaining what continuous integration is.
Along with last chapter, it forms our guidelines for onboarding reviews.
2.1 Why use continuous integration (CI)?
All rOpenSci packages must use one form of continuous integration. This ensures that all commits, pull requests and new branches are run through
R CMD check. rOpenSci packages’ continuous integration must also be linked to a code coverage service, indicating how many lines are covered by unit tests.
Both test status and code coverage should be reported via badges in your package README.
2.2 How to use continuous integration?
usethis package offers a few functions for continuous integration setup, see the documentation.
Details will be provided below for different services.
2.3 Which continuous integration service(s)?
Different continuous integration services will support builds on different operating systems.
R packages should have CI for all platforms when they contain:
Dependencies on other languages
Packages with system calls
Text munging such as getting people’s names (in order to find encoding issues).
Anything with file system / path calls
In case of any doubt regarding the applicability of these criteria to your package, it’s better to add CI for all platforms, and most often not too much hassle.
2.3.1 Travis CI (Linux and Mac OSX)
Travis offers continuous integration for Linux and Mac OSX. Set it up using
Please use these tips to minimize build time on Travis especially after your package project gets transferred to ropensci Travis account:
2.3.2 AppVeyor CI (Windows)
For continuous integration on Windows, see R + AppVeyor. Set it up using
Here are tips to minimize AppVeyor build time:
Cache installation of packages. Example in a config file. It’ll already be in the config file if you set AppVeyor CI up using
Enable rolling builds.
We no longer transfer AppVeyor projects to ropensci AppVeyor account so after transfer of your repo to rOpenSci’s “ropensci” GitHub organization the badge will be
[![AppVeyor Build Status](https://ci.appveyor.com/api/projects/status/github/ropensci/pkgname?branch=master&svg=true)](https://ci.appveyor.com/project/individualaccount/pkgname).
2.4 Test coverage
Continuous integration should also include reporting of test coverage via a testing service such as Codecov or Coveralls. See the README for the covr package for instructions, as well
If you run coverage on several CI services the results will be merged.
2.5 Even more CI: OpenCPU
After transfer to rOpenSci’s “ropensci” GitHub organization, each push to the repo will be built on OpenCPU and the person committing will receive a notification email. This is an additional CI service for package authors that allows for R functions in packages to be called remotely via https://ropensci.ocpu.io/ using the opencpu API. For more details about this service, consult the OpenCPU help page that also indicates where to ask questions.
2.6 Make more of your CI builds: tic
tic package facilitates deployment tasks for R packages tested by Travis CI, AppVeyor, or any other CI tool of your choice, cf e.g. our suggestion to build and deploy the documentation website of your package via Travis. Actually this book uses
tic for deployment.