Automatically build, compile and release SuperCollider plugins using Github Actions
Since the main SuperCollider github repository moved to using Github Actions to automatically build, compile and release cross platform, I felt intrigued to use the same technology to do the same for SuperCollider plugins.
There is a number of amazing SuperCollider plugin repositories on Github - a lot will demand that the user compiles the sourcecode themselves to use the plugins. For people used to CMake and/or a Linux-ey workflow of compiling, this is not a big problem but for a lot of others (most people perhaps), it really is a doorstopper.
Thankfully, we can automate all of this.
For the developers, this means that whenever they push a new version tag, Github will automatically compile and package everything nicely.
For the users, this will make it easy them to find and download the correct version of the plugins for their operating system of choice.
If you want to see a live example of this, I do this in my own personal plugin repository.
How to set up Github Actions to build and publish SuperCollider plugins
I have written a configuration file for Github Actions that makes this whole process fairly easy for plugin developers. It is all based around a .yaml-file containing a list of commands to be run to build the plugins. These are the same commands you would use locally to build the plugins basically, but for macOS, Linux and Windows in one go.
- Add this yaml file to
.github/workflowsin your git repo.
- Edit the file to change all of
MKPluginsto whatever you want your asset (this is the zip file containing your prebuilt release) to be called.
- Then, locally run
git add -f .github/workflows/build.ymland
git commit .github/workflows/build.yml -m "Add GH action"to add this file to your project.
- Push the file to
mainbranch on Github:
- Open up Github.com and navigate to your repo, click the “Actions” pane and select your workflow. This is where you will be able to see your “jobs” running in realtime (and potential errors they give off).
Create a release
The way the yaml file is set up, it will activate the process whenever the github repository receives a new tag containing
v*, where the asterisk is some version number (for example
To activate this, in your local git repo you may run this command to
# Create a version tag git tag v0.0.108 # Push new version tag to GH and activate action git push origin --tags