autopkg
Posts about autopkg written by apizz
https://secure.gravatar.com/blavatar/85a60c61ca17945252af5b3f9082f81376805d0b032142bc9333e4b7989875df?s=32
apizz
A while ago, I’d run into an uncommon scenario where a piece of software I was attempting to incorporate into an autopkg workflow (https://github.com/TigerVNC/tigervnc) which had its project on GitHub did not include downloadable assets for the software with these releases. Instead, these were hosted on an entirely different website (Sourceforge). Normally, using the GitHubReleasesInfoProvider processor you would just provide the org and project information, but the processor expects at least one published asset and without this it produces an error.

Initially I’d filed an autopkg issue to incorporate an additional variable which doesn’t require an asset, but it proved easier to simply use the URLTextSearcher processor instead to acquire the necessary version information.

While the versioning scheme of software may vary, the below example & regex (re_pattern) will work for the majority of software on GitHub including those that use semantic versioning (ex. releases: v10.2.1; 5.0.30):

<dict> <key>Comment</key> <string>Get latest release version number from GitHub</string> <key>Arguments</key> <dict> <key>re_pattern</key> <string>/releases/tag/v?([\d.]+)</string> <key>result_output_var_name</key> <string>version</string> <key>url</key> <string>https://github.com/<org>/<project>/releases/latest</string> </dict> <key>Processor</key> <string>URLTextSearcher</string> </dict>

If you find yourself in a similar situation, you can find more information on the autopkg wiki page I created: https://github.com/autopkg/autopkg/wiki/GitHub-Releases-with-No-Assets

It’s been a minute since I felt I had something worthwhile to write about. In the past, the autopkg systems I had configured either had plenty of internal storage or external storage available to more or less “set it and forget it”. The consequence of this approach is over time if you have many software titles your autopkg cache folder will become quite large. Depending on the recipes you use, say you have many that involve naming downloaded or packaged software with the version, this can also greatly increase the size because new software version downloads and packages don’t overwrite the previous ones. So if you find yourself like I do where free space is precious on your autopkg system, you need an automated way to clean it.

While I haven’t yet taken the leap to implement autopkg in a CI workflow that makes this whole issue moot, I wrote a script to periodically clean out old downloads, packages, as well as the tmp files that can result from incomplete downloads.

As written, running this on the command line will remove any .dmg, .pkg, .tar.gz, and .zip files older than 7 days. It also removes those pesky tmp files that can get leftover from incomplete software downloads. This can also be triggered to be run as part of a LaunchDaemon.

If you wish, you can tweak the threshold for removing old files by entering your own day value for DAYS_TO_DELETE. Additionally, if you wish to exclude any items that would normally be deleted, uncomment the EXCLUSIONS variable and enter any desired search terms.

Happy cleaning!