GitHub Actions for Pulumi
I just recently created abatilo/pulumi-composite-actions which is an adapted version of the official pulumi/actions.
They’re largely the same in terms of end result but with some minor changes.
A bit ago, GitHub released the ability to do what they call “composite” GitHub Actions. At launch, GitHub Actions basically let you run either a node action or a Docker action. The Docker actions were super convenient but the node based actions had a huge advantage over them. The node based actions didn’t require any kind of build step. They only needed to clone the repository of the action and could immediately execute. Docker images either needed to be downloaded first, or built, which usually implied downloading base images. These could be super slow which was really annoying for CI workflows.
On top of slow execution, GitHub Actions charge you based on build and execution time. So the slower your actions took to build, the more you’d get billed.
A pattern emerged with GitHub Actions to instead just install tools directly to the host and execute commands from there. This is when you started seeing actions like actions/setup-node or actions/setup-python. This pattern enabled much faster workflows as compared to what we originally did.
I had created abatilo/actions-poetry a while back but it was so ridiculously slow to run because what we did was install a version of Python with pyenv and then install poetry and THEN run your command args. Compiling and installing Python took a long time, then having to install poetry itself. It was pretty common for the build and install of poetry to take longer than the poetry command that was ran.
A composite action is basically letting you package together a bunch of bash scripts to run on the host. So you could have a different GitHub Action step do the install and have one step that’s just executing commands with the assumption that the tool is already available.
So assuming you installed Pulumi a different way, for example with the official pulumi/action-install-pulumi-cli, my abatilo/pulumi-composite-actions would just use whatever version was installed.
Pulumi addressed this themselves by making their action use the Pulumi Automation API which is just turning their tool into an importable library. Their action is now just a node based action which is a clone and execute. So why would you still want to use my composite action?
Firstly, their official action will currently create a PR comment for every single execution, even if there’s no changes. There’s an issue open on their repo about trying to have some way to denote whether or not there are changes so that a later step could write the comment. My pulumi-composite-action will actually only comment on a PR if there are changes reported.
The second big feature that my action adds is the built in ability to retry on failures. Pulumi recently merged in a change that lets Pulumi do state file locking on the S3 backend like terraform already does. If the stack is locked, Pulumi just fails immediately. So if you had two PRs open close enough to each other that had the state locking enabled, one PR would report that it failed to do the preview because it couldn’t acquire the lock. Pulumi’s state locking doesn’t have a wait timeout like terraform’s does, so we have to retry to acquire the lock.
You can see an example of usage of the new actions on my abatilo/blog repository since pulumi is how I deploy the website:
- uses: abatilo/pulumi-composite-actions@main
if: github.event_name == 'pull_request'
env:
GITHUB_TOKEN: $
with:
passphrase: $
command: preview
stack: blog
- uses: abatilo/pulumi-composite-actions@main
if: github.event_name == 'push'
env:
GITHUB_TOKEN: $
with:
passphrase: $
command: up
stack: blog
These actions let you have a fully declarative, git powered workflow. You don’t even need to have Pulumi installed or AWS credentials available at all in order to make infrastructure changes. And since everything is in git, everything is completely audited and reviewable!