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.
