This works until you have a bug you can't replicate on a developer machine that your CI misses. This is a common thread on open source projects:
> issue opened October 2013
> __ is broken on MacOS
> __ should fix it but I don't have a Mac to test.
> issue opened October 2013
> __ is broken on MacOS
> __ should fix it but I don't have a Mac to test.
> I do have a Mac but ___ can’t be replicated on my specific dev-tainted environment, plus I’m using macOS Y and you use macOS Z which is a pain for me to set up a VM for, if at all possible.
The raise of a few free macOS CI mitigated that a bit but the offer is honestly poor (except at CircleCI, props to them), and seems like Apple could care less so much they’re now actively making that harder than ever.
If Apple should be sued for anti-consumer behavior this is why... It costs time and money to fix software with every MacOS release and I'm getting close to suggesting we add a 50% Apple tax on products to pay for the additional support it entails.
As a matter of fact I went through the trouble to set up 10.9 through 10.14 in VirtualBox, driven by gitlab-runner via the virtualbox executor[0] (which is pure genius: it uses linked VM clones from a reference VM to spawn parallel runners, as well as using snapshots once SSH is ready after first boot for <2s spawn + full state reset).
Given the painful macOS on VirtualBox situation, at the time I wanted to move to VMware Fusion[1] but lacked time to implement an executor. It seems someone took that in their own hands and implemented a specific runner (in Swift!).
[0]: https://docs.gitlab.com/runner/executors/virtualbox.html
[1]: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1679
[2]: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1679#no...