Juce and CICD : how?

My release process is getting more and more complicated as my project grows, so I’m looking for advice on how to setup a nice build pipeline that could manage all of the details for me. I’ve used Jenkins at a previous job before and I liked being able to trigger builds from an interface, but im completely clueless on how it would work with Juce. I’m imagining this is possible now that we have CMake support?

What I would love to be able to do when its time for prod:

  1. Trigger a build which would connect to a windows and mac machine and build the latest changes for both platforms
  2. Create the installers with the proper release version, this would involve updating some of the fles required by the install progrrams im using (packag for mac, iss for windows)
  3. Sign the installers using the certificates and processes I define
  4. Finally upload the files to a n s3 bucket of my choice

How can I set something like this up? Just need some general advice so I can research and start trying to get this to work.

Curious also if anyone set ever used a service for a virtual mac before so i can do the mac portion, my access to a mac is only through my job and I’d like to break that dependency

Cheers!!

1 Like

I’d recommend looking at GitHub Actions (assuming you use GitHub for your code). You can do Windows, macOS & Linux builds in the cloud. The only thing I haven’t figured out is a cloud based way to do AAX signing.

You can look at example build script here: https://github.com/FigBug/PAPU/blob/master/ci/build.sh

It gets latest projucer, resaves .jucer, builds, signs, notarizes, and uploads if on release branch.

1 Like

I agree with @g-mon checkout GitHub Actions. Regarding the AAX signing, you can either have a different stage in your build that runs on a local machine that is connected to GitHub Actions or contact PACE as I know they offer a cloud signing service although I’ve never used it personally.

My tip is to get a script working locally that does everything you want then using whatever CI you have all you need to do is call the script. The reason for this is…

  1. You can run the script locally to debug it
  2. It makes it easier to switch CI services

Hope that helps.

1 Like

Also “Extended Validation Code Signing” on Windows and “Notarization” on macOS can be problematic to put in CI, no?

No problems doing notarization in CI. I don’t think you can do Extended Validation Code Signing since it requires a dongle and user interaction.

2 Likes

Yeah “Extended Validation Code Signing” will need a dongle so it will have to be done on a local machine but GHA supports local and remote nodes for Windows, macOS, and Linux, so it at least allows keeping local nodes to the bare minimum.

1 Like

GitHub Actions looks perfect - thanks for the tip also on writing a script that works locally and going from there, that helps shape where I should start. Cheers guys!