GitHub Actions for R: Introducing the ghactions package

GitHub actions are a new workflow automation feature of the popular code repository host GitHub. The product is currently in limited beta .

Among many other things, it allows you to run (pretty much arbitrary) Continuous Integration / Continuous Delivery (CI/CD) workflows.
Sort of like TravisCI, but arguably way more flexible.

I got into the limited beta while back and have been using it for a couple of weeks now.
I think it's pretty amazing, and it may have some potential for R users.
A gif says is best:


(This is a complete package build/check/doc/deploy workflow).

To benefit from all the inherent flexibility, GitHub actions is arguably best used via GitHub's own visual editor (at (You may be relieved to learn that there's always a flat text representation behind the visual editor that you can edit by hand).

Still, I thought, it might be great to have simple templates with sensible defaults for many R projects. So @FrauK and I built a package for that:

This package is meant to get you started quickly, as well as a place to gather and distill experiences and best practices.

I've also developed a couple of R-specific GitHub actions, which you'll also find documented there. (These are, technically, separate from the package, though the package provides convenient wrappers).

Here's how to get started.

Throughout, I've found GitHub actions to be really easy to work with, quite performant, and generously supported by GitHub.

The aspect I like the most is that the each of the actions making up a workflow, each have their own Docker image to run in.

Though this has some upfront cost, being thus forced to bring-my-own-dockerfile has been a blessing in my development workflow, and I've even turned to developing inside those Docker images.
Finally, I've had to provision only one computing environment per project.
Docker is not, without additional measures, a reproducibility panacea, as RStudio has cogently argued.

But still, beats wrestling with TravisCI for me :slight_smile:.

I was also happy to read that GitHub has already open sourced the actions spec and parser, and seems to encourage a wide range of community implementations, including running it locally as a makefile of sorts.

So the vendor lock-in is hopefully going to be relatively limited, especially because it's all Docker and Shell underneath.

It's obviously still early days for GitHub actions itself, and especially the ghactions package, with lots more to do (especially testing, more project support, build artifact caching, and much more.).

This being a beta project, GitHub also cautions against usage in production context, and the same holds for my package.

Still, I thought I'd put this out there.

Can't wait to hear your feedback.


I went through quickly and it looks really cool!

Probably won't be using it for now since we are not ready to switch to GitHub for that, but still wanted to make one comment.

Do you think it's a good idea to use rocker images in development? I mean, you certainly don't need RStudio when you build the package and you almost certainly don't need all of the tidyverse. Would it make sense to point people (in documentation, for example) to base-r image and then add extra packages as needed?

1 Like

thanks for the feedback @mishabalyasin!

I thought about this as well, and decided to make ghactions fundamentally Dockerfile agnostic: you (mostly) have to bring-your-own-Dockerfile (byod), and that can be verse, or something way slimmer. (The exception is if your project in question has a definitive target run- or buildtime environment, such as

That said, (tidy)verse has the advantage that you can also docker run inside these locally, and just develop inside them. For that, you obviously need a "fatter" image with RStudio and other bells and whistles not strictly necessary for rendering.

I'm still considering ways to make using slimmer images easier, but haven't settled on a good and easy-to-use way to do this.
Multi-stage Dockerfiles look very promising, but I'm not sure how that could be done with exiting Rocker images.

I'm also going to look carefully at the images used by RStudio in production at and

I actually think that some amount of standardising on a few, popular images, even if that comes with some heft, might be worth our while for many (especially RMarkdown) projects that don't need dramatic scale.

This looks amazing, I have been on the beta for a while and it makes total sense for R given its GitHub focus. I hope to turn my blogdown website workflow into using this package to help set it up, and migration from Travis for private packages, deploying plumber APIs onto Kubernetes and more.


glad to hear you're also enjoying GitHub actions!

I haven't tested blogdown with ghactions yet, but it should work. (Tested rmarkdown and bookdown and still figuring out an elegant way to do real testing for this pkg).

There'll be more GitHub actions shortly, and I'm also looking into making it super easy to offload HPC stuff to beefier cloud machines (via cloudyr, of course!).

Let me know how this works for you and else you might need from the pkg or in terms of R github actions.

Thanks for your work on this!

Trying out GitHub actions for R has been on my todo list for a few months now but I haven't gotten the time to do more than look through the documentation, great to see you pushing it further!


GitHub actions has really been a bit of a catalyst for me, causing me to use Docker in development and CI/CD and production, finally cutting down on the madness of provisioning the same computing environment several times (as I discussed with @cole and @MarkeD here). (I know I could've used Docker on TravisCI for a long time, and GitHub actions doesn't really change that much – just reduces friction).

Anyway, there's still lots of questions I have about how to best use GitHub actions in R, and I'd love any feedback or thoughts people might have about this.

My preliminary idea for ghactions is to do as little as possible in R, because I thought GitHub actions itself provides a UI/UX that's probably hard to improve upon without increasing the complexity. (I'm not a great fan of just wrapping everything in R).

That said, (more) quick templates seem like a good idea, because they can save everyone a lot of clicks.

But most of the work probably lies in developing more custom R actions (technically outside of any package), and in evolving best practices.


Just having a repo of R focused tasks you can move into your own GitHub actions will be a useful starting point I think, its a bit confusing for someone starting where and how to use the Dockerfiles etc. so a step by step showing from start to finish a few examples should cover the bases and encourage more customisation in the future.

1 Like

that's helpful feedback @MarkeD, thanks. The whole docker circus can be a bit daunting for newcomers, I guess.

I opted for the image-agnostic rscript-byod, because I'd otherwise have to hard code some R Docker image (verse? tidyverse? something smaller?) into the action, which seemed awkward.
(GitHub actions doesn't – for now – let users choose among several images for an action. Every action runs in one image via the uses: field).

Maybe just defaulting on verse will be fine.

Anyway, I'm going to add some more actions where there is a definitive build/run-time image (e.g.

For those cases, users clearly don't have to deal with Docker.

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.