The goal of tic is to enhance and simplify working with continuous integration (CI) systems.

The following ones are supported:

Provider R package Platforms Info
Appveyor CI {r-appveyor} Windows
Circle CI {circle} Linux via Docker images from rocker
Github Actions {ghactions} Linux, macOS, Windows
Travis CI {travis} Linux, macOS and

To learn more about CI, read the “Travis CI for test automation” blog post and our Getting Started vignette.

The most important improvements over existing solutions are:

  1. Deployment to a Git repository is greatly simplified. Update your repository with results from the CI build.

  2. Support for R packages and other kinds of projects (bookdown, blogdown, etc.), with predefined templates. Set up your project to deploy rendered versions of your book or blog with a single push to Git.

  3. Workflow specification in a single .R file, regardless of CI system used.
    Forget about .yml files or web browser configurations.


{tic} can be installed from GitHub with:



By calling tic::use_tic() a production ready CI setup is initialized, tailored to your specific R project. The created templates will use the providers (; see this FAQ for more info),, and

If only the CI YAML templates from {tic} are desired, the use_<provider>_yml() functions can be used. Refer to the complete list of options.

For an R package, the following steps will be set up for the CI workflow:

  • Installation of required dependencies for the project (dependencies are scraped from the DESCRIPTION file*)
  • Satisfying build-time dependencies of steps to be run in all CI stages (by scraping pkg::fun calls in tic.R)
  • Checking of package via rcmdcheck::rcmdcheck()
  • Creation of a pkgdown site including Github deployment
  • Running a code coverage and upload to

See the Getting Started vignette for more information and links to minimal example repositories for various R projects (package, blogdown, bookdown and more).


If you are a new user, run


If you already use {tic} and want to configure a new CI provider, do

## Travis CI
travis::use_travis_deploy() # (optional for deployment)
tic::use_travis_yml(type = )
tic::use_tic_r("package", deploy_on = "travis")

## Circle CI  
circle::use_circle_deploy() # (optional for deployment)
tic::use_circle_yml(type =  )
tic::use_tic_r("package", deploy_on = "circle")

## Appveyor
tic::use_appveyor_yml(type = )

## Github Actions
tic::use_ghactions_deploy(deploy = TRUE)
tic::use_ghactions_yml(deploy = TRUE)
tic::use_tic_r("package", deploy_on = "ghactions")

Good to know

We would like to mention that {tic} is a choice and sits on top of existing community efforts providing R support for various CI providers. While {tic} will prevent you from dealing/learning every CIs YAML syntax, you will have to learn {tic}’s way of specifying your tasks on CI systems.

Also, there is no way around familiarizing yourself with the basics of CI systems in general. Without this knowledge, you will also have a hard way understanding {tic}.

We also recommend to take a look at the projects providing the direct R support for each CI system (which {tic} builds upon) to gain a deeper understanding of the whole concept.


There is not yet an automated way of updating the templates installed by {tic}, hence you need to manually check every once in a while if changes were made to the templates. Have a look at the changelog for possible changes to YAML templates or watch the commit history of the CI templates you are using. An update mechanism is on our list (see issue #194) but it may take some time.


All examples listed here should work on all CI providers listed above. The badges link to the most recent build of the master branch.


The setup functions in this package assume Git as version control system, and GitHub as platform. Automated setup works best if the project under test is located in the root of the Git repository. Multi-project repositories are not supported, see the comment by @jwijffels for guidance to work around this limitation.