In ropenscilabs/travis: Set Up 'Travis' for Testing and Deployment

knitr::opts_chunk$set(
  collapse = TRUE,
  comment = "#>"
)

Authentication

The first time any function of {travis} is called, it will check for the existence of a Travis API key (for the respective endpoint). This is a one-time procedure and needs to be done for each endpoint .org and .com. Without the API key, no requests to the API of Travis CI can be made. In addition a GITHUB_PAT is needed to make API calls to GitHub. If you have not set one within .Renviron yet, call usethis::browse_github_token() and follow the instructions.

When calling browse_travis_token(), a browser window will open. After logging in, the API key for the respective endpoint can be copied.

This key can be stored in

environment variables R_TRAVIS_ORG or R_TRAVIS_COM (recommended)
or in file ~/.travis/config.yml (see ?browse_travis_token() for help)

Storing it in one of these is enough. The second option is provided because it represents the way an API key is stored when using the Travis CI CLI tool.

Setting the default endpoint

Travis announced in May 2018 to migrate open-source repositories from https://travis-ci.org to https://travis-ci.com. Since then, two endpoints (.org and .com) exist on which users can run their builds. To make it easier for the users to specify a default for the endpoint when using the {travis} package rather than having to specify the endpoint argument in all functions, one can set the environment variable R_TRAVIS in .Renviron to the desired endpoint. If none is set, {travis} will by default use the .org endpoint.

# example for .com
R_TRAVIS = ".com"

Migrating from .org to .com

Since there is quite some confusion on the difference of these endpoints and if one should migrate, we try to give some answers:

There is no difference in features between the endpoints
Once migrated an account/organization to .com via the migrate button, there is no way back. Meaning there is no chance to start builds ever again on .org.
Via the API one could in the past enable repositories on both endpoints without a full migration. However, this seem to have changed lately upstream on Travis CI and might now work anymore.

We will not make a statement whether you should migrate your repositories to the .com endpoint. However, at some point Travis CI will probably force the migration and since the endpoint exists since quite some time, things should be somewhat stable.

How {travis} scrapes the repository information

{travis} scrapes information about the current repository from Github (currently only Github is supported). To do so, {travis} looks at the git repo slug and extracts the information.

Then, the {gh} package is used to query information about the repository and the current user. This is important for some functions which try to add keys (SSH keys, deploy keys) to the Github repo or to Travis CI.

For this, the {gh} package needs access to the Github API via and relies also on a token, in this case a GITHUB_TOKEN. You can create one using usethis::browse_github_token() (if you haven't done so yet) and store it as an environment variable again.