We’re in the fantastic situation where lots of people are using Travis-CI to test their R packages or use it to test and deploy their analytics/ documentation / anything really. It’s popularity has been having a negative side-effect recently though! GitHub rate limits API access to 5000 requests per hour so sometimes there are more R related jobs running on Travis per hour than this limit, causing builds to error typically with a message that includes

403 forbidden

This error will cause your build to fail, even if you didn’t do anything wrong. To solve it short-term you can wait a little while and restart your build.

How to restart a build in Travis-CI
How to restart a build in Travis-CI

That is a very short-termist solution and does not solve the problem for future you or other users of the service. The real solution to resolving this issue is to get off the default API access credentials and use your own.

The R integration in Travis makes good use of the devtools. The devtools package looks for an environment variable called GITHUB_PAT that holds a personal access token (PAT) for using the GitHub API and if it doesn’t find one it uses a default token. When we get our own PAT and store it in Travis, devtools will pick up our token and use it, meaning you’ll only ever get rate limited if you do more than 5000 builds in an hour, which is an achievement I’d love to hear about.

How to

  1. Create a PAT with no permissions i.e. untick all the permissions boxes
  2. Copy the key
  3. Go to your repo’s settings on Travis e.g. https://travis-ci.org/stephlocke/Rtraining/settings
  4. Add an environment variable called GITHUB_PAT and paste in your key. There is a toggle next to it that defaults to not show the value in the log. This key has no permissions but still, keep it private and don’t toggle!

Stay secure

If you followed the instructions above your key will be conforming to the principle of least privileges because it will only be able to perform public actions that anyone can take i.e. read and clone a public repository. That being said, it’s never wise to let credentials escape out into the wilderness unless you can avoid it. This is where the bit about ensuring the value doesn’t get printed to the log comes in. If it never gets printed, the only time this key is available for stealing is when you’re creating it and adding it to Travis.

Verifying it worked

When you next run a build, you should see some (or all) of the following signs of success, over and above a lack of a 403 error:

Setting environment variables from repository settings
$ export GITHUB_PAT=[secure]

$ Rscript -e 'devtools::install_github("stephlocke/tfsR",dependencies=TRUE)'
Using GitHub PAT from envvar GITHUB_PAT
Using Travis? Make sure you use a Github PAT
Tagged on:                     

7 thoughts on “Using Travis? Make sure you use a Github PAT

  • 13/04/2016 at 08:00

    I don’t think you can secure a PAT in this way.

    If a PAT was of any value and I wanted to intercept it, I would submit a pull request to your project that modified travis.yaml to include the printenv GITHUB_PAT command. Since github automatically submits PRs to travis, I would know your PAT before you could notice the shady pull request and take any action.

  • 13/04/2016 at 09:41

    Thanks for this, I had no idea I should be doing it! Very easy to follow instructions and it works as stated.

  • 13/04/2016 at 14:04

    The rate limit for unauthenticated requests is actually only 60 per hour, which is why this happens fairly often on Travis and Appveyor when using devtools.

    Devtools 1.11.0 (just released yesterday) includes a PAT that is shared between all devtools CI builds, which will raise the limit from 60 per hour per IP to 5000 per hour (shared) and should reduce the incidence of this issue.

    Setting a personal GITHUB_PAT is still the best way to avoid hitting the GitHub rate limit though.

    • 13/04/2016 at 16:24

      Ah so that’s 60 per Travis Docker container IP?


What do you think?