# r-lib/actions, the GitHub Actions that the R community shares instead of rewriting

> The r-lib actions repository holds the reusable GitHub Actions the R community uses to install R, restore packages, run R CMD check and manage pull requests in R repositories. The actions are versioned on a major tag, and the repository also ships a set of example workflows that show how they fit together, from a standard package check to bookdown, pkgdown, Quarto and coverage runs.

**r-lib/actions** — GitHub Actions for the R community

- Repository: https://github.com/r-lib/actions
- Stars: 1,067 · Forks: 234
- Language: TypeScript
- License: CC0-1.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/r-lib-actions

## Nine actions, and the CI tasks they cover

The action list is short enough to read in one go, and it covers the pipeline of an R project. setup-r sets up R itself. setup-r-dependencies installs the packages declared in the DESCRIPTION file, and setup-renv installs packages from an renv lockfile, which are the two different ways an R project declares its dependencies. setup-pandoc sets up pandoc, and setup-tinytex sets up LaTeX with tinytex, which together are what you need for rendering R Markdown and bookdown output. check-r-package runs R CMD check on an R package, which is the one action every package needs. The last two are for repository automation: pr-fetch fetches changes of a pull request associated with an event, and pr-push pushes changes to a pull request associated with an event. setup-manifest is the odd one out, setting up an R project with a Posit Connect manifest.json file.

```yaml
- uses: r-lib/actions/setup-r@v2
```

## The major tag moves, the fine-grained tag does not

The versioning policy is stated explicitly and it is the thing to get right when you write a workflow. Major version tags mark breaking changes in these actions, and for the current version you should use the v2 tag. The v2 tag occasionally changes to introduce non-breaking fixes and improvements, and those changes use more fine-grained tags such as v2.0.1, which you can also refer to in your workflow files if you need to. So there are two reasonable strategies and they trade against each other. A floating v2 tag means your CI picks up upstream fixes without you touching anything, which is usually what you want, and a pinned fine-grained tag means your build is reproducible but you own the upgrade. The release notes for the v2 tag are kept current with the changes in v2, and the repository's own default branch is v2-branch, which is what the tag and the branch names reflect.

```
We use major version tags to mark breaking changes in these actions.
For the current version, please use the `v2` tag
```

## The examples directory, which is the real documentation

The repository ships an examples directory of workflow files, and the list of names is a map of what people actually build. The check workflows come in five flavours: check-full, check-release, check-standard, check-no-suggests and html-5-check, which reflect the fact that R CMD check has knobs and a project has to choose what it checks. There are bookdown and blogdown workflows, each in a plain and a gh-pages variant, which is the difference between rendering a book and also deploying it. pkgdown.yaml covers site generation, document.yaml covers the manual, render-rmarkdown.yaml renders documents, shiny-deploy.yaml deploys a Shiny app, and test-coverage.yaml handles coverage. There are also style and lint workflows, a lint-changed-files variant, pr-commands.yaml for pull request automation, and an example for Claude to investigate. Each of these is a starting point you copy and adjust, and the pattern is that the example is the documentation.

```
setup-r
setup-r-dependencies
setup-renv
setup-pandoc
setup-tinytex
check-r-package
pr-fetch
pr-push
setup-manifest
```

## Two platform traps, documented with the fix

The common questions section is short and the two entries are the ones every R CI user eventually hits. The first: why are builds with plots failing on macOS? The answer is that you need to install XQuartz to do plotting with the default quartz device on macOS, and the fix is a conditional install step in the workflow. The second: why are Windows builds failing with an error about configure.ac having CRLF line endings? On Windows, when your repo is checked out using git, the line endings are automatically changed to CRLF, and R's check process specifically checks if the configure.ac file has these line endings and will error if it does. The fix is a .gitattributes file, which the truncated documentation points at. Neither of these is a bug in the actions, and both are the kind of detail that costs an afternoon once and then nothing again, which is the value of having them written down.

```yaml
- if: runner.os == 'macOS'
  run: brew install --cask xquartz
```

## The Makefile that generates the project's own workflows

The repository uses the same actions it publishes, and the Makefile shows a neat trick for dogfooding. The workflow files are generated from the examples with a chain of perl substitutions, and the first substitution replaces every reference to r-lib/actions/<action>@v2 with a relative path to the local directory, so the project's own CI runs the code in the working tree rather than the published tag. The remaining substitutions pin third-party actions to exact commit hashes with the version in a comment, for instance actions/checkout at a specific commit with a v6.0.2 comment, and the same for upload-artifact, the codecov action and the github-pages-deploy action. The last substitution adds v2-branch to the list of branches, since the default branch is not main or master. A make target lists the workflow files it generates, and there is a clean target that removes them.

```make
all : $(WORKFLOWS)

clean:
	rm -f $(WORKFLOWS)
```

## This is an R package too, and that is deliberate

The repository is not only a directory of YAML. It is also a valid R package, with a DESCRIPTION file, a NAMESPACE, an R/ directory, a src/ directory, tests/, vignettes/, a _pkgdown.yml, a CITATION.cff and a Makefile, which is what lets the actions be released, versioned and documented with the same tooling as any other R package. The .Rbuildignore keeps the non-package parts out of the build, and the actions.Rproj file opens the whole thing in RStudio as a project, which is how you would develop an action that is written in R. The presence of a .clusterfuzzlite/ directory is worth a second look too, because fuzzing infrastructure next to a CI action repository usually means something in the action is parsed from untrusted input, and the fuzz target is there to keep that parsing safe. The licence is CC0-1.0, and the last push to the repository was on 2026-10-12.

```
DESCRIPTION
NAMESPACE
R/
src/
tests/
vignettes/
_pkgdown.yml
CITATION.cff
```

## Where to look when a build breaks

The help section is a debugging procedure rather than a support channel, and it is worth following in order. First, figure out what caused the error, and look for the first time the word error appears in the build log, because quite often errors at the end of the log are caused by an earlier issue, so it is best to look for the root cause. Second, take advantage of GitHub's code search to find similar yaml files, with the path filter restricted to workflow files, and the documentation gives a concrete example: if you need to install geospatial libraries such as gdal, search for gdal with that path filter, and if you want results only from workflows that use R, add the setup-r term. Third, open an issue on the RStudio community, linking the workflow file and a failing build. If the issue is about GitHub Actions but not about R, the GitHub Actions Community page is the right place, and if you are sure it is a bug in one of the R specific actions, check for an open issue in this repository first and look at the pinned issues, which the project says affect many people and often contain workarounds.

```
Look for the _first_ time the word
Quite often errors at the end of the log are caused by an earlier
issue, so it is best to look for the root cause.
```

## The scope, and the parts it deliberately leaves out

The repository is scoped to R and it says so. The project points at quarto-dev/quarto-actions for Quarto related work, namely install, render and publish, which is the boundary drawn with the adjacent tool. It also warns about the age of the advice you will find online: content published prior to the Fall 2019 is probably outdated because the beta version of GitHub Actions was different, and more recent posts may be outdated too since the actions evolve, so the advice is to refer to the GitHub Actions official documentation and to the changelog in case of doubt, and to existing working workflows. One more limit is worth naming for anyone extending these actions: a new major feature needs testing, typically by running a GitHub Actions workflow on the R package in the repository. The default branch is v2-branch, the last push was on 2026-10-12, and the repository is not archived.

```
Adding a major feature also needs testing, typically by running a
GHA workflow on the R package in this repository.
```

## Conclusion

Adopt r-lib/actions if you maintain an R package or an R-based site on GitHub Actions and want the CI setup that the rest of the community already uses, because a working R CI pipeline is a piece of work you should not have to invent. Skip it if you need a general purpose CI framework, since this is a set of R-specific actions rather than a pipeline tool. Verify three things before you copy a workflow: which major tag you reference, since the v2 tag moves and a fine-grained tag pins the exact build; that the R version you want is available in setup-r rather than assumed; and the two platform gotchas the project documents, the XQuartz requirement for plotting on macOS and the CRLF line ending problem with configure.ac on Windows.

## FAQ

### What does the r-lib/actions repository provide?

Reusable GitHub Actions for R projects that can be used to do a variety of CI tasks: setup-r, setup-r-dependencies, setup-renv, setup-pandoc, setup-tinytex, check-r-package, pr-fetch, pr-push and setup-manifest, along with a set of example workflows that use these actions.

### How should I reference the r-lib actions in a workflow?

With the major version tag, for example `- uses: r-lib/actions/setup-r@v2`. The v2 tag occasionally changes to introduce non-breaking fixes and improvements, and those changes use more fine-grained tags such as v2.0.1, which you can also refer to if you need to pin an exact build.

### Why do my R builds fail on macOS with plots?

You need to install XQuartz to do plotting with the default quartz device on macOS. The documented fix is a conditional step in the workflow: `- if: runner.os == 'macOS'` followed by `run: brew install --cask xquartz`.

### What is the r-lib actions setup-renv action for?

It installs packages from an renv lockfile, as opposed to setup-r-dependencies, which installs the packages declared in the DESCRIPTION file. Between them they cover the two common ways an R project declares its dependencies.

## Sources

- [Issues](https://github.com/r-lib/actions/issues)
- [License: CC0-1.0](https://github.com/r-lib/actions/blob/v2-branch/LICENSE)
- [README](https://github.com/r-lib/actions/blob/v2-branch/README.md)
- [Releases](https://github.com/r-lib/actions/releases)
- [r-lib/actions on GitHub](https://github.com/r-lib/actions)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/r-lib-actions