GitHub Actions are sweet! It's still in beta but it's a great way to automate tasks after things happen like code pushes, comments on Issues, pull requests, etc.
As an author of a GitHub Action, I'm really enamored by the architecture: each "build" is run on a virtual machine in Azure, with each action running inside a Docker container that GitHub executes. As Kyle Daigle mentions on a Changelog podcast::
As a small developer my entire side business could be a Docker container. Not running it, not supporting the payment for it, just a Docker container.
GitHub does this by building and executing your Docker container on the fly. So if you want your Action to finish quickly, you'll want to spend some time optimizing.
These are lessons I've learned building an action to execute a Particle function. I'm not an expert, but they worked for me!
Optimization 1: Use a container deployed to Docker Hub
You can reference an action by pointing to a GitHub repository containing its source:
# Compiled just-in-time
uses: mattdsteele/particle-action@master
But, the first step for each of your user's workflow will be to checkout the action's source and compile the container. This takes time!
So, if you build the container and publish it to a Docker registry like Docker Hub:
# Precompiled, users just pull the container
- uses: docker://mattdsteele/particle-github-action:latest
For my particular action, this improves builds by over 60 seconds!
Of course, you'll need to build and upload your container each time you push a change to your action. Luckily, there's a GitHub Action for that :)
Optimization 2: Trim your Docker images
When referencing a Docker registry, GitHub has to download the image each time. And if you're not careful, Docker containers can be massive, which can slow down how fast your action executes. So the smaller you can make your container, the better.
Don't rely on a big parent image
My first version of the action relied on curl, which even on a large-ish base like Debian wasn't available by default. So here's where I started:
$ docker images
REPOSITORY SIZE
particle-bash 90.8MB
Switching from Debian to a smaller Linux base like alpine is a great way to start optimizing:
REPOSITORY SIZE
particle-alpine 12.6MB
Better!
Build a self-contained executable in Go
Going further, we can use Go to build a single, self-contained executable that doesn't rely on any operating system tools! So, I rewrote the action, switched the base to FROM golang:latest, and got this:
REPOSITORY SIZE
particle-golang 810MB
Yikes! This is due to Docker images being additive; so the container includes the entire Go build toolchain.
Use a Docker multi-stage build
Let's fix this by setting up a Docker multi-stage build, where we build the Go binary in one stage, and copy it into the empty "scratch" image:
# build stage
FROM golang:alpine AS build-env
RUN apk --no-cache add build-base git gcc ca-certificates
COPY go.mod particle.go /src/
RUN cd /src && go build -o main
# final stage
FROM scratch
COPY --from=build-env /src/main /
COPY --from=build-env /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
ENTRYPOINT ["/main"]
(I also had to copy over the SSL certificates to the scratch image, since I was making HTTPS calls.)
REPOSITORY SIZE
particle-scratch 7.27MB
Nice!
Optimize the Go binary
We can optimize the image size further by optimizing the Go binary with a couple flags:
RUN cd /src && CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-w -s" -o main
Another improvement:
REPOSITORY SIZE
particle-scratch-optim 5.33MB
In total, these optimizations took my GitHub action from a 6+ minute run down to 30 seconds. Pretty sweet when you're waiting for the action to complete to get candy.