Can we enable CI for legacy systems?

[Ryan Schmidt]

On Jan 24, 2021, at 17:52, Ruben Di Battista wrote:

> I think that one of the selling points of Macports, at least for me, is providing ports for legacy systems. So on the ports I maintain, I try to fix build issues on old systems. The problem is that it’s very difficult to do it since I need to merge blindly something and wait for the buildbots. 
> 
> Is there a way to use the buildbots as CI for legacy systems? That would really help... I could try to hack something out if you are interested, provided you can give me a bit of guidance on understanding how they work… They look pretty misterious to me. :)

The short answer is no, we cannot "enable" CI for legacy systems. We can "spend a lot of time reimplementing the CI system on our own infrastructure" but nobody has done that yet.

Our existing buildbot infrastructure stays running all the time, more or less. The VMs aren't rebooted except for maintenance reasons. This relies on the fact that the commits that are built there have already been vetted by MacPorts developers. There is some degree of assurance that the commits are "good" and won't trash the system.

There is no such assurance when building code submitted in a pull request, since anyone with a GitHub account can submit a PR. It could contain "bad" or even malicious code. This is why our existing CI infrastructure (formerly using Travis CI and now using Azure Pipelines and GitHub Actions) starts up a clean VM for each pull request, installs MacPorts and the port's dependencies, tries to build the port, reports the results, then throws the VM away. These third party CI systems do not offer older versions of macOS, so to offer that, we would have to recreate their infrastructure on our own hardware. There has been talk of doing this, but nothing concrete has emerged.

We also don't have much spare server capacity. With all of the different OS versions for which we build on the four Xserves that run the buildbot, the SSDs and RAM are just about full. Running additional VMs on the existing hardware would also slow down the other VMs since they're all competing for the same CPUs. We could buy more RAM and bigger SSDs or even additional servers, but MacPorts doesn't have a revenue stream so the existing buildbot hardware purchases have been paid for by me, and I don't want to commit to buying endless additional hardware. However, money is the least of the problem right now. If we had the software created and all that we needed was money to buy hardware, I'm sure it could be found.

So with what we have now, it is fine to commit changes to ports that you *think* will fix a problem, even if you haven't verified the fix because you don't have access to the particular system where the problem occurs. This is relevant for Apple Silicon systems as well, since we don't have Apple Silicon build machines on our CI system yet. And this is what we did years ago before we had moved to GitHub, before we had pull requests, before we had CI systems.

If you're interested in supporting older systems, you can install older OS versions on your Mac, either in separate volumes or partitions if your hardware supports booting to older OS versions, or in virtual machines with VMware Fusion, Parallels Desktop, or Oracle VirtualBox.