Github actions

Photo by Oleg Magni from Pexels

I know this seems like a tiny problem compared to everything else that has happened in 2020. But I started the year having learnt how to use Travis CI. This meant I could put my hobby projects under some kind of continuous testing. Now, whatever the merits of various workflows that can used for CI, Travis was supported by the R community. It was well integrated into R package development. Unfortunately, after an acquisition and a restructure, Travis have recently announced that they are dropping the free tier for open source projects. I have no objection to paying for a service, and certainly suspect had I been using tools like Travis for the last 15 years I would have saved myself huge amounts of time and stress. It’s possibly even more important to have CI given my development habits, which go in fits and starts depending on other commitments. I can certainly remember needing to give a live demonstration and finding out that a package upgrade had broken all my code (and to make things worse, there was no question of using an earlier version of the software on the presentation machines). That said, there are plenty of developers who feel Travis have gone back on earlier promises regarding a free tier. Whatever the rights and wrongs, the bigger issue for me is that the R package building integration will likely move away from supporting Travis as thoroughly as it does just now.

Consequently, I’ve just spent a few days setting up GitHub Actions. I made the slight mistake of taking the guidance from the GitHub docs directly. If I had looked at the R resources a little more carefully I would have seen that the usethis package contains a use_github_action_check_standard() function which sets everything up in your project/package folder including the yaml file needed to run GitHub actions. Anyway, following some trial and error, I now have a combination of GitHub community actions. GitHub actions check out the project repository and R-specific GitHub actions (available on GitHub itself) allow installation of an appropriate version of R. The R-Lib people also provide example workflows to conduct testing on Linux (Ubuntu), MacOS and Windows.

I seemed to have my usual problem of needing to install some Ubuntu packages (header files to allow C++ compilation). I guess the answer to that really is to specify a docker image that can be used locally and run under GitHub actions, but that is something I will look into another day. For now, one of my use cases is testing code against the latest release of R, and seeing what breaks while I’ve been busy on other projects.

In terms of code coverage, after considerable effort fighting to persuade emacs to give me some coverage analysis, I find (of course) there is an off-the-shelf R package covr that does this beautifully. This package sends output to codecov.io. Yes, that’s built another free tier service into my tech stack. However, it produces beautiful summaries of code coverage as well as some gratuitous visualisations. The only current downside is that all the results are open to the world to see. That’s an incentive to plug some obvious holes in code coverage! It certainly buys time to try to get code coverage working as I want in emacs.

All-in-all, after two days of grouching, it looks as if GitHub actions is a perfectly viable CI tool for a simple open source project. My next challenge will be to see if this blog itself can be automatically deployed through a GitHub action whenever its source files are updated. There is a pre-canned example in R-Libs GitHub actions. Things may work much more smoothly if you fit in with community supported workflows.