Dependencies that you can't or won't pin versions of in a reliable persistent cache, have the potential for drift.  Such is the life of my dotfiles repo.  I don't want to pin most things there.  It is an outlier relative to what you might normally set up to produce the most consistent, reliable build process.   For dotfiles, I want to lean way in towards making sure they stay current even if it breaks once in a while in exchange for that posture.

One of the challenges of making sure a dotfiles repo continues to function correctly on a clean machine is that running through them for the first time, in a clean environment, is a rare activity.  It generally only happens when I am configuring a new laptop or others are installing it for the first time.  

If I could do a clean install on a more regular basis, it would decrease the chance that little breakages are piling up over time.  This is where a most basic form of continuous integration comes in.

I am starting with a sanity test . . .

Can the install script execute, start to finish, without error?

I have already seen this break when a dependency is renamed or when I introduce a subtle syntax error that someone finds in a fork when they try to run everything clean for the first time.  I want to catch those issues as quickly as possible.

GitHub Actions for MacOS dotfiles CI

When perusing the GitHub Actions documentation, I noticed they included the ability to run an action on a MacOS VM!

wat.

For free.

wat.

For open source repositories.

oh, yah ok.

Still . . . In case you are not aware, getting a hosted MacOS VM, while possible, is generally not cheap relative to other server options.  The fact that Github is offering [free] to run Mac workloads for opensource projects is a cause for celebration.

Ok.  Let's get to the meat of it:  GitHub Actions are behaviors you define in a yaml file checked in to the repository itself.  

To get started I defined a 'Smoke Test CI' workflow in .github/workflows/smoke.yml in my dotfiles repo:

name: Smoke Test CI

on: [push]

jobs:
  build:

    runs-on: macOS-latest
    
    steps:
    - uses: actions/checkout@v1
    - name: Execute full install
      run:  ./setup.sh

Every single push to the dotfiles repo provisions a temporary MacOS VM, checks out the code with git, and executes the full install of the dotfiles (via ./setup.sh).  

The results for the builds that are triggered are in the Actions tab for that Repository on Github:

and you can drill in to see the results of each step and the logs:

That's it!

Getting this set up has already caught some bugs.**

**One caveat: For a small handful of things, I had to detect that I was running inside a GitHub action and skip over them because they required privileges that were locked down or not available on that VM.  Prudently, Github provides some default environment variables in the VM when running inside a Github Action.  I used those as a clue to skip them.