Building your plugins with Continuous Integration (CI) comes with great advantages:
- Reduced workflow friction. No more manually jumping between a mac and windows machine to trigger and wait for builds.
- Peace of mind. With pluginval running against each build, and any tests you add, you can feel safe that your plugin will at least load in DAWs on all platforms.
- Consistency. You can be sure each build is built the way the last build was built. This eliminates a whole class of variables and issues.
- Automated releases and publishing to your site / storefront.
Building in CI entails some overhead.
Some companies say they spend 10% of their time maintaining their build systems.
I probably spend at least a solid week a year dedicated to it, plus a few hours every few months.
But I’m also maintaining Pamplejuce and pluginval, so I have more work than you would have. On the other hand, I also have deep knowledge (most of which I’ve attempted to dump in this manual).
However you cut it, after you are up and running, you should expect to spend some time in the future banging your head against red builds and dealing with dependency and ecosystem changes.
The most annoying part about working with GitHub Actions is pushing and waiting for a build to fail and pushing again.
What Maintaining a Pamplejuce-based project looks like
Things that are likely to happen:
- You’ll need to update which GitHub runners you are using. GitHub is fairly aggressive about deprecating old versions of operating systems, typically only keeping the last 3 from each platform in rotation.
- You’ll need to update
JUCEand thecmakesubmodule as the ecosystem evolves. - Pluginval will complain about some recent changes in your plugin and you may need to need to run it locally to figure out what the problem is.
Leave a Reply