I am getting an error when using one of travis::use_travis_deploy(), circle::use_circle_deploy() or tic::use_ghactions_deploy().


In most cases this is related to API authentication issues. Ensure that the following points are met:

  1. For Circle CI and Travis CI, install the respective GitHub App from the GitHub Marketplace.
  2. Ensure that you have set the respective API keys for the problematic provider in your .Renviron file. Consult the help pages of the respective use_*_deploy() function for more help.
  • GitHub Actions: A GITHUB_PAT with “public_repo” scopes.
  • Travis CI: Env var R_TRAVIS_ORG or R_TRAVIS_COM, depending on the endpoint you use.
  • Circle CI: Env var R_CIRCLE.

GitHub Actions


How is {tic} different from what r-lib/actions does?


{tic} uses r-lib/actions as the base to install R in the first place. However in detail, {tic} does the following things differently which aim to enhance the CI experience:

  • Caching: {tic} caches the whole R library rather than only the direct dependendencies of a package. This has the advantage that packages required for side actions ({pkgdown} deployment, README updates) will also be cached.

  • ccache: {tic} comes with a compiler cache for source installations of packages by default, speeding up repeated source installation highly. The compiler cache directory (.ccache) will also be cached (once a week). Example use case: If you installed {Rcpp} from source as a dependency of your package and have it stored in your cache and {Rcpp} now updates two days later, the reinstallation will make use of the compiler cache and install {Rcpp} instantly rather than recompiling the C code again.

  • Number of CPUs: {tic} uses 4 CPUs by default instead of only 1 as r-lib/actions does. This speeds up package installation a lot. 4 CPUs are max because all GitHub Actions runners have 2 hyperthreading cores available.

  • Use of SSH deployment keys: Once set up via tic::use_ghactions_deploy(), this deployment approach makes it possible to push any file of your repository to any branch of your remote. Other deployment approaches often limit you to only push to gh-pages branch or similar.

Travis CI


What is the difference between and and which one should I use?


When dealing with Travis CI (or the {travis} package) the first time, one might be confused what the difference is between and This devops.stackexchange question gives some insights on the history of both services and why both still exist.


I am seeing conflicts when deploying a pkgdown site during deployment - it looks like multiple runners are facing a git race condition. I am getting errors like


Correct. This is because multiple runners building and deploying the pkgdown site nearly at the same time. To prevent this from happening (doing this for one runner is enough) condition the pkgdown step to one runner by setting an env var.

In tic.R:

and then set this env var for one of the runners in .travis.yml:

Appveyor CI



I am facing the following build error:


Do you have a private SSH key stored as a secure environment variable in the in appveyor.yml? If yes, it could be that you encrypted while being logged in to a different account than the one the repo is running under in reality. This means if you have access to multiple organizations and your private account on Appveyor, you need to encrypt the environment variable using the account in which repo lives.



Is it possible to update the CI YAML templates installed by {tic} with upstream changes?


Yes! Have a look at “Updating Templates” for more information.


Am I the only one using {tic}?


You can see who and how many people use {tic.R} on GitHub via this query:


Package {rgl} fails to install because of either

  • “configure: error: X11 not found but required, configure aborted.”
  • “error: X11 not found; XQuartz (from is required to run rgl.”


The first one is usually caused by a missing installation of XQuartz on macOS. Add brew cask install xquartz to the runner.

The second error requires to set the DISPLAY env var to mimic a non-headless state. Add export DISPLAY=:99 to the stage in which {rgl} should be installed. If the warning message during loading of {rgl} should be suppressed, either env var RGL_USE_NULL = TRUE can be set or R option options(rgl.useNull = TRUE).