Hi Ryan, thanks for your answer. If I configured a server I own to run CI jobs for old systems (I was thinking about using a custom Gitlab runner libvirt https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html for that and maybe), it's gonna be something useful that Macports could potentially use?
PS: Does Github Action support custom "executors" to eventually run libvirt? On Mon, Jan 25, 2021 at 3:55 AM Ryan Schmidt <[email protected]> wrote: > > > 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. > > > -- _ -. .´ |∞∞∞∞ ', ; |∞∞∞∞∞∞ ˜˜ |∞∞∞∞∞∞∞∞∞ RdB ,., |∞∞∞∞∞∞ .' '. |∞∞∞∞ -' `' https://rdb.is
