Welcome to post 56 in the R4 series.
The recent post #54 reviewed a number of earlier posts on r-ci, our small (but very versatile) runner for continunous integration (CI) with R. The post also introduced the notion of using a container in the ‘matrix’ of jobs defined and running in parallel. The initial motivation was the (still ongoing, and still puzzling) variation in run-times of GitHub Actions. So when running CI and relying on r2u for the ‘fast, easy, reliable: pick all three!’ provision of CRAN packages as Ubuntu binaries, a small amount of time is spent prepping a basic Ubuntu instance with the necessary setup. This can be as fast as maybe 20 to 30 seconds, but it can also stretch to almost two minutes when GitHub is busier or out of sorts for other reasons. When the CI job itself is short, that is a nuisance. We presented relying on a pre-made r2u4ci container that adds just a few commands to the standard r2u container to be complete for CI. And with that setup CI runs tend to be reliably faster.
This situation is still evolving. I have not converted any of my
existing CI scripts (apart from a test instance or two), but I keep
monitoring the situation. However, this also offered another
perspective: why not rely on a different container for a
different CI aspect? When discussing the CI approach with Jeff the other day (and helping add CI to his
mmap repo), it occurred to me we could also use on of
the Rocker containers for
R-devel. A minimal change to the underlying run.sh script
later, this was accomplished. An example is provided as both a test and
an illustration in the repo for package
RcppInt64 in its script ci.yaml:
strategy:
matrix:
include:
- { name: container, os: ubuntu-latest, container: rocker/r2u4ci }
- { name: r-devel, os: ubuntu-latest, container: rocker/drd }
- { name: macos, os: macos-latest }
- { name: ubuntu, os: ubuntu-latest }
runs-on: ${{ matrix.os }}
container: ${{ matrix.container }}This runs both a standard Ubuntu setup (fourth entry) and the
alternate just described relying on the container (first entry) along
with the (usually commented-out) optional macOS setup (third entry). And
line two brings the drd container from Rocker. The CI runner script now
checks for a possible Rdevel binary as provided inside
drd (along with alias RD) and uses it when
present. And that is all that there is: no other change on the user
side; tests now run under R-devel. You can see some of the initial runs
at the rcppint64
repo actions log. Another example is now also at Jeff’s
mmap repo.
It should be noted that this relies on R-devel running packages made with R-release. Every few years this breaks when R needs to break its binary API. If and when that happens this option will be costlier as the R-devel instance will then have to (re-)install its R package dependencies. This can be accomodated easily as a step in the yaml file. And under ‘normal’ circumstances it is not needed.
Having easy access to recent builds of R-devel (the container refreshes weekly on a schedule) with the convenience of r2u gives another option for package testing. I may continue to test locally with R-devel as my primary option, and most likely keep my CI small and lean (usually just one R-relase run on Ubuntu) but having another option at GitHub Actions is also a good thing.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.