Automate builds with a cloud service

[kzantow]

I'm investigating automating builds using a cloud service -- Azure Pipelines apparently allows for both Windows and macOS for free for open source projects; I almost created a working pipeline for macOS, it would be nice to get 'nightly' builds at least for now, and have some way of automating release. Unless someone else has a better idea.

I started looking around after I noticed Mac Stadium allowed free macOS compute time for open source projects: https://www.macstadium.com/opensource

If anyone knows any other services offering free compute time for Windows + Visual Studio build tools and/or macOS + XCode build tools, please do post them here!

[kurasu]

pretty much.. I had a look at @kzantow 's script in the multi-target-branch build and it seems he does a commit for each build at the end, which I assume we don't want, but other than that it looks pretty great at first glance

[baconpaul]

Cool. Yeah it does a commit because kzantow pushes it to his github.io. Can the azure bot publish a github release on this repo?

[kzantow]

@kurasu @baconpaul yeah, that's the thing -- the release script is currently doing a commit to update the version. If there are any suggestions how to make that happen, I'm all ears! The other issue is actually publishing the binaries -- it's currently pushing these to gh-pages, which I don't find ideal at all. Unfortunately, using the GH api to push "releases" needs an actual user to access the API rather than a per-repository SSH key. I think for now, I'll just set up a specific repository for the built releases so it can have a deploy key only for that (which will be hidden in the Azure secrets config, not the build script).

Anyway, this is long winded but any ideas for how to update version back in the repo, would be great!

[baconpaul]

I’m sorry I have no specific experience or ideas in this regard! But that at least means I’ll be happy with whatever you end up liking. Sorry!

[kurasu]

@kzantow Can't we skip the release part for now (strip out that part of the script) and just use the build for code verification purposes initially and worry about getting automatic releases as a second step? That would be super useful especially at this point where there so cross-platform layer work being done.

Regarding version numbers, could we use branch names for that? I.e we would create a branch named 1.6 for the 1.6 release and build from that. And if the branch name is not a valid version number it gets a numerical version number of 0.0.0 but still shows that name in the about box, along with build date & revision.

[kzantow]

@kurasu yeah, I'll make a PR with an updated script tonight. As for releases, if the strategy is to always just make a release (or maybe more ideally just tag? though I don't know if tags will work) with something like release/1.6, release/1.6.1 etc., I think it would be pretty easy to trigger the actual release behavior off of that with branch-based conditional portions of the build. And then probably push to an alternate 'release' repository.

[esaruoho]

The VS projects need to be set up so that there are two "Configurations" for Win32 and x64, then on Azure just a matter of having two "Build Solutions" (this is using msbuild behind the scenes), with the appropriate "Configuration" and the "Platform" set to "Win32" or "x64" to correspond.

thanks @asimilon ! i've mirrored this stuff (32bit) to #115 - with the hopes we'll eventually come up with 32-bit windows+macos builds for vst2/vst3. would be really cool. btw, are you able to join the Surgesynth Slack? here's an invite: https://join.slack.com/t/surgesynth/shared_invite/enQtNTE4OTg0MTU2NDY5LTE4MmNjOTBhMjU5ZjEwNGU5MjExODNhZGM0YjQxM2JiYTI5NDE5NGZkZjYxZTkzODdiNTM0ODc1ZmNhYzQ3NTU