Can we enable CI for legacy systems?

[Ruben Di Battista]

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 <ryandesign at macports.org>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20210125/ec21b68d/attachment.htm>