AutoPkg is a software packaging system for macOS, commonly paired with Munki for distribution. For many organizations, Munki is the default way to coordinate the installation and updating of applications on macOS. At Gusto we use it to provision new machines and update existing ones. We’ve been running AutoPkg on Github Actions since late 2019 […]
AutoPkg is a software packaging system for macOS, commonly paired with Munki for distribution. For many organizations, Munki is the default way to coordinate the installation and updating of applications on macOS. At Gusto we use it to provision new machines and update existing ones. We’ve been running AutoPkg on Github Actions since late 2019 and wanted to share how we set up our build pipeline.
AutoPkg refers to the steps required to package a specific utility as “recipes,” which define elements like code signature validation, supplemental installation scripts, and installer download locations. Github Actions is a CI/CD service offering Windows, GNU/Linux, and macOS runners charged per minute of run time. Github Actions is one of the few CI services that offer macOS runners billed by the minute, which is useful for short jobs like AutoPkg recipe runs.
Prior to moving our AutoPkg builds to Github Actions, we ran our AutoPkg recipes on a dedicated VM that was hand built and manually updated. It was our house plant; things were mostly fine day to day, but regular maintenance was required and someone needed to watch it when we went on vacation. Any upgrades to the base OS or AutoPkg required careful testing and a rollback plan. In the worst case scenario a disk failure could have resulted in the loss of our entire build process, which thankfully never happened.
Interacting with the box was a bit of a pain too, since we kept access pretty locked down for security reasons. The host machine was located on-premises and required VPN. We couldn’t get our desktop support team interested in adding recipes when users requested new apps because we had no review process and everyone was afraid that clicking the wrong button would cause the machine to explode.
To make sure we’re rolling out the latest version of applications, we run our AutoPkg build daily. As mentioned earlier, we use Github Actions VMs to save us the headache of maintaining our own build infrastructure.
Our daily Github Actions AutoPkg run does the following:
In a future release of macOS, only signed package installers will be able to be deployed. I’d like to add our developer cert as a Github Actions Secret to sign internal packages and free software tools built from source.
Since we’re running AutoPkg in ephemeral VMs, we discard cached downloads and end up downloading packages again each day even though we’ve already imported the same version into our internal package repository. We’re planning on submitting an upstream patch to the AutoPkg project to optionally read package download history from a file on-disk or hosted elsewhere, which should significantly speed up AutoPkg runs.
We’re eager to see how other organizations are using Github Actions or similar CI systems for running tasks that previously required a dedicated VM, like AutoPkg or Terraform. Hopefully, sharing our process helps make managing software packaging on macOS a little bit easier for you.