GitHub Actions Day 5: Building in Containers
This is day 5 of my GitHub Actions Advent Calendar. If you want to see the whole list of tips as they're published, see the index.
Yesterday I talked about how to install tools and dependencies on the GitHub Actions virtual environments. But what if you need still more control? Or what if you don't want to run on Ubuntu at all? This is where containers shine.
By creating a container that contains all the development tools that you need and your project's dependencies, you don't have to worry about managing those set up and installation steps at the beginning of your workflow run.
Plus, you get the advantages of container-based development: you can build locally in the same container that you use for CI builds, so you have a high degree of confidence that your builds in GitHub Actions match what you see when you're building locally.
The syntax for this is surprisingly straightforward - I don't need
to run any docker pull
or docker run
commands myself. GitHub
Actions takes care of this for me. To get my sources and run my
tests in the node:current
container:
When I run this workflow, GitHub Actions will download the container
that I specified from DockerHub, start it, and then execute the
run
steps that I specified within the container directly.
Note that you still need to specify the
runs-on
when you're running within a container. This is because both Linux and Windows support containers - so if you want to run Linux-based containers, then you wantruns-on: ubuntu-latest
. If you want Windows-based containers, then be sure to setruns-on: windows-latest
.
Containers can also help expand your build matrix: if you want to build and test your tool across multiple different Linux distributions, then you can even set up your container jobs in a matrix. (Since matrix workflows are really just variable subtitution.)
For example, to build on both legacy and cutting edge releases of Debian, Ubuntu and CentOS:
So you have flexibility about where your workflows run, whether you want to build directly on a virtual environment that we provide, or in a container that you specify.