Can we enable CI for legacy systems?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Can we enable CI for legacy systems?

Ruben Di Battista
Hello,

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. :)



          _   
-.     .´  |∞∞∞∞
  ',  ;    |∞∞∞∞∞∞
    ˜˜     |∞∞∞∞∞∞∞∞∞ RdB
    ,.,    |∞∞∞∞∞∞
  .'   '.  |∞∞∞∞
-'       `’

https://rdb.is
Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

ryandesign2
Administrator


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.


Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Ken Cunningham
In reply to this post by Ruben Di Battista
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.
If you would like to set up a VM or several to help do this, it is very easy, I found.

I like Parallels, and it does VMs from 10.5 to BigSur on my 2010 MacPro 5,1 running Mojave.

I put them all on one 1TB SSD.

All the systems from 10.7 to BigSur are available free from Apple, as are the Xcode setups, the documentation, and the command line tools.

10.5 and 10.6 you have to find in Server editions to run on Parallels. VirtualBox runs my 10.4 Intel VM.

I think it's really hard to just throw things at the buildbots and hope they stick.

Best,

Ken

Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Andrew Janke
Hi Ken,

On 1/24/21 11:34 PM, Ken Cunningham wrote:
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.
If you would like to set up a VM or several to help do this, it is very easy, I found.

I like Parallels, and it does VMs from 10.5 to BigSur on my 2010 MacPro 5,1 running Mojave.

I put them all on one 1TB SSD.

All the systems from 10.7 to BigSur are available free from Apple, as are the Xcode setups, the documentation, and the command line tools.


How do you download the installers for Big Sur and for older versions of macOS? I've always had to go through the App Store to download installers, and what it makes available for me is dependent on the current OS version and hardware of my Mac. And half the time, when I try to create a new VM using an old version's installer, the installer process tells me "This installer has been damaged" and refuses to continue. (This happens on installer copies that had worked in the past. I assume it's some sort of certificate problem.)

I ask because I've been trying to set up a VM-based build farm for Octave and Octave.app (https://octave-app.org/) and not having much luck.

Cheers,
Andrew
Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Joshua Root-8
On 2021-1-25 18:48 , Andrew Janke wrote:

> How do you download the installers for Big Sur and for older versions of
> macOS? I've always had to go through the App Store to download
> installers, and what it makes available for me is dependent on the
> current OS version and hardware of my Mac. And half the time, when I try
> to create a new VM using an old version's installer, the installer
> process tells me "This installer has been damaged" and refuses to
> continue. (This happens on installer copies that had worked in the past.
> I assume it's some sort of certificate problem.)
>
> I ask because I've been trying to set up a VM-based build farm for
> Octave and Octave.app (https://octave-app.org/) and not having much luck.

Recent versions can be downloaded here:
<https://support.apple.com/en-au/HT211683>

The rest are available at <https://developer.apple.com/download/more/>.

- Josh
Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Wowfunhappy@gmail.com
In reply to this post by Ruben Di Battista
> The rest are available at <https://developer.apple.com/download/more/>.

That link contains old versions of Xcode for me, but not old operating systems. I wonder, Joshua, do you have  a paid Apple developer account? (I do not.)

> And half the time, when I try to create a new VM using an old version's installer, the installer process tells me "This installer has been damaged" and refuses to continue.

Depending on the version of macOS, you may be able to silence that by popping into the Terminal. https://apple.stackexchange.com/questions/216730/this-copy-of-the-install-os-x-el-capitan-application-cant-be-verified-it-may-h/232016#232016
Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

ryandesign2
Administrator
In reply to this post by Joshua Root-8


On Jan 25, 2021, at 01:55, Joshua Root wrote:

> On 2021-1-25 18:48 , Andrew Janke wrote:
>> How do you download the installers for Big Sur and for older versions of macOS? I've always had to go through the App Store to download installers, and what it makes available for me is dependent on the current OS version and hardware of my Mac. And half the time, when I try to create a new VM using an old version's installer, the installer process tells me "This installer has been damaged" and refuses to continue. (This happens on installer copies that had worked in the past. I assume it's some sort of certificate problem.)
>> I ask because I've been trying to set up a VM-based build farm for Octave and Octave.app (https://octave-app.org/) and not having much luck.
>
> Recent versions can be downloaded here: <https://support.apple.com/en-au/HT211683>
>
> The rest are available at <https://developer.apple.com/download/more/>.

OS versions are only available in the developer download area for paid Apple developer program members. Free Apple developer program members can't access OS installers there and should use the support article above (to download 10.10 or later) or the Purchased tab of the Mac App Store (to download 10.7-10.9). Only older OS installers that you previously downloaded from the Mac App Store will be in the Purchased tab.

Apple redesigned how the App Store works in macOS Mojave, so there can indeed be some difference in the what you get from the App Store depending on whether you download on 10.14-or-later or 10.13-or-earlier.

The certificate Apple used to sign its installer packages expired October 24, 2019. Any Apple installers for the OS or anything else that you may have saved that were signed with that certificate are now unusable. Throw them out and download new versions of those installers now; most of them have been re-posted signed with newer certificates.

Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Ruben Di Battista
In reply to this post by ryandesign2
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Andrew Janke
In reply to this post by ryandesign2


On 1/25/21 10:31 AM, Ryan Schmidt wrote:

> On Jan 25, 2021, at 01:55, Joshua Root wrote:
>
>> On 2021-1-25 18:48 , Andrew Janke wrote:
>>> How do you download the installers for Big Sur and for older versions of macOS? I've always had to go through the App Store to download installers, and what it makes available for me is dependent on the current OS version and hardware of my Mac. And half the time, when I try to create a new VM using an old version's installer, the installer process tells me "This installer has been damaged" and refuses to continue. (This happens on installer copies that had worked in the past. I assume it's some sort of certificate problem.)
>>> I ask because I've been trying to set up a VM-based build farm for Octave and Octave.app (https://octave-app.org/) and not having much luck.
>> Recent versions can be downloaded here: <https://support.apple.com/en-au/HT211683>
>>
>> The rest are available at <https://developer.apple.com/download/more/>.
> OS versions are only available in the developer download area for paid Apple developer program members. Free Apple developer program members can't access OS installers there and should use the support article above (to download 10.10 or later) or the Purchased tab of the Mac App Store (to download 10.7-10.9). Only older OS installers that you previously downloaded from the Mac App Store will be in the Purchased tab.
>
> Apple redesigned how the App Store works in macOS Mojave, so there can indeed be some difference in the what you get from the App Store depending on whether you download on 10.14-or-later or 10.13-or-earlier.
>
> The certificate Apple used to sign its installer packages expired October 24, 2019. Any Apple installers for the OS or anything else that you may have saved that were signed with that certificate are now unusable. Throw them out and download new versions of those installers now; most of them have been re-posted signed with newer certificates.
>
Ah, that explains it. Guess I'll re-up my Developer membership...

Andrew
Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

ryandesign2
Administrator
On Jan 25, 2021, at 10:03, Andrew Janke wrote:

> On 1/25/21 10:31 AM, Ryan Schmidt wrote:
>> On Jan 25, 2021, at 01:55, Joshua Root wrote:
>>
>>> On 2021-1-25 18:48 , Andrew Janke wrote:
>>>> How do you download the installers for Big Sur and for older versions of macOS? I've always had to go through the App Store to download installers, and what it makes available for me is dependent on the current OS version and hardware of my Mac. And half the time, when I try to create a new VM using an old version's installer, the installer process tells me "This installer has been damaged" and refuses to continue. (This happens on installer copies that had worked in the past. I assume it's some sort of certificate problem.)
>>>> I ask because I've been trying to set up a VM-based build farm for Octave and Octave.app (https://octave-app.org/) and not having much luck.
>>> Recent versions can be downloaded here: <https://support.apple.com/en-au/HT211683>
>>>
>>> The rest are available at <https://developer.apple.com/download/more/>.
>> OS versions are only available in the developer download area for paid Apple developer program members. Free Apple developer program members can't access OS installers there and should use the support article above (to download 10.10 or later) or the Purchased tab of the Mac App Store (to download 10.7-10.9). Only older OS installers that you previously downloaded from the Mac App Store will be in the Purchased tab.
>>
>> Apple redesigned how the App Store works in macOS Mojave, so there can indeed be some difference in the what you get from the App Store depending on whether you download on 10.14-or-later or 10.13-or-earlier.
>>
>> The certificate Apple used to sign its installer packages expired October 24, 2019. Any Apple installers for the OS or anything else that you may have saved that were signed with that certificate are now unusable. Throw them out and download new versions of those installers now; most of them have been re-posted signed with newer certificates.
>>
> Ah, that explains it. Guess I'll re-up my Developer membership...

If you like, but you can get released OS installers without it, as detailed above.

Paid developer membership does give you other perks, like prerelease OS versions.

Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

ryandesign2
Administrator
In reply to this post by Ruben Di Battista


On Jan 25, 2021, at 10:02, Ruben Di Battista wrote:

> 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?

I'm not sure how comfortable we would be with running builds on other users' hardware, but if you can develop the software process for cloning a template VM, getting buildbot or whatever running on it, accepting a job from a GitHub PR notification, and so forth, then we could possibly deploy it on our hardware. We currently use VMware ESXi on our Intel hardware. We do not have a plan yet for what we would do with Apple Silicon hardware.

> PS: Does Github Action support custom "executors" to eventually run libvirt?

I can't answer that. I haven't looked into how the CI systems we use work.

Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Ruben Di Battista
Ok, thanks Ryan. I'll think about it.

I'd do it on Gitlab, since they allow custom executors for their CI and I'm familiar with it. Reading about Github Actions, that does not seem possible and I'm not extremely familiar with Github APIs. If someone has ideas, feel free to send them my way.

I'll update you when (and if) I'll have something useful.

On Mon, Jan 25, 2021 at 5:10 PM Ryan Schmidt <[hidden email]> wrote:


On Jan 25, 2021, at 10:02, Ruben Di Battista wrote:

> 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?

I'm not sure how comfortable we would be with running builds on other users' hardware, but if you can develop the software process for cloning a template VM, getting buildbot or whatever running on it, accepting a job from a GitHub PR notification, and so forth, then we could possibly deploy it on our hardware. We currently use VMware ESXi on our Intel hardware. We do not have a plan yet for what we would do with Apple Silicon hardware.

> PS: Does Github Action support custom "executors" to eventually run libvirt?

I can't answer that. I haven't looked into how the CI systems we use work.



--
          _  
-.     .´  |∞∞∞∞
  ',  ;    |∞∞∞∞∞∞
    ˜˜       |∞∞∞∞∞∞∞∞∞ RdB
    ,.,    |∞∞∞∞∞∞
  .'   '.  |∞∞∞∞
-'       `'
https://rdb.is
Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Ken Cunningham
In reply to this post by Ruben Di Battista
there is another way to download older os versions.

It leverages the netboot method that lets me boot from and install, from Apple, a new copy of 10.7 on my MacBookPro 9,1 during a rescue mode boot.

There are various python scripts available that ask you what system you want, then download it without using the App store or developer.apple.com.

Ken
Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Clemens Lang-2
In reply to this post by Ruben Di Battista
Hi,

GitHub Actions supports self-hosted runners, see
  https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners

I personally wouldn't have a problem with optional CI steps running on
other people's machines, as long as that's for pull requests and we
don't use the results anyhere but to post status information to GitHub.

Stricly speaking, the hosted VMs from Azure we're currently using are
"other people's machines", too.

--
Clemens
Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

ryandesign2
Administrator


On Jan 25, 2021, at 11:37, Clemens Lang wrote:

> I personally wouldn't have a problem with optional CI steps running on
> other people's machines, as long as that's for pull requests and we
> don't use the results anyhere but to post status information to GitHub.

There would be an advantage to having the CI system on the same local network as the private packages server: not needing to upload private packages through my relatively slow upstream internet connection. Anyway, where we host it is a moot point until there is something to host.

Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Mojca Miklavec-2
In reply to this post by Ruben Di Battista
On Mon, 25 Jan 2021 at 17:02, Ruben Di Battista
<[hidden email]> wrote:
>
> 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?

Yes, definitely.

There are a couple of independent requirements:
(a) we need the software / CI jobs definitions
(b) we need the hardware to run those jobs on
(c) ideally a not-too-complicated way to set up & fire up VMs with
different macOS versions would be really handy
    (both in terms of a set of scripts to set up a new VM, as well as
the sequence to fire up the VM / build the port / destroy the copy)

I suspect that we would be able to find some hardware somewhere once
we have the software written.
The last point sounds like most of the work.

Maybe GitLab runner isn't able to run on the oldest macOS that we
support, but if you run it on the host just to fire up a VM, that
might be ok.

I see that GitLab supports CI on top of GitHub repository:
    https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html

Maybe that's not as straightforward as if the repo was stored on
GitLab directly, but it still sounds perfectly fine if you get it
working.

Even if you just start with your own clone of the GitHub repo inside
GitLab and get it working, this would still represent some 90 % of the
job (majority of [a] and complete [c]).

> PS: Does Github Action support custom "executors" to eventually run libvirt?

I'm not so familiar with GitHub Actions, but we are currently using
buildbot for the official builds. That one certainly offers native
libvirt support:
    https://docs.buildbot.net/latest/manual/configuration/workers-libvirt.html

(Just getting the images done will likely take some non-trivial amount of time.)

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Ken Cunningham
In reply to this post by Ruben Di Battista
Clemens linked in some documentation to the github application runner that said it ran on 10.13+ only.

If that's true -- not of much use for a legacy CI test runner, it would seem, unless somehow that can still work...
Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Mojca Miklavec-2
On Wed, 27 Jan 2021 at 15:45, Ken Cunningham wrote:
>
> Clemens linked in some documentation to the github application runner that said it ran on 10.13+ only.

I'm aware that most of the systems require a relatively recent macOS
(buildbot worker runs on ancient systems without any major issues
though).
I actually wanted to point that out also for the gitlab runner.

But then it hit me that if you only use the worker/runner on the host
computer (which can run any macOS version) which starts a fresh VM and
sends the build instructions to that VM, I guess that an ancient VM
might still work?

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

ryandesign2
Administrator
In reply to this post by Mojca Miklavec-2
On Jan 27, 2021, at 06:32, Mojca Miklavec wrote:

> Maybe GitLab runner isn't able to run on the oldest macOS that we
> support, but if you run it on the host just to fire up a VM, that
> might be ok.
>
> I see that GitLab supports CI on top of GitHub repository:
>    https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html
>
> Maybe that's not as straightforward as if the repo was stored on
> GitLab directly, but it still sounds perfectly fine if you get it
> working.
>
> Even if you just start with your own clone of the GitHub repo inside
> GitLab and get it working, this would still represent some 90 % of the
> job (majority of [a] and complete [c]).
>
>> PS: Does Github Action support custom "executors" to eventually run libvirt?
>
> I'm not so familiar with GitHub Actions, but we are currently using
> buildbot for the official builds. That one certainly offers native
> libvirt support:
>    https://docs.buildbot.net/latest/manual/configuration/workers-libvirt.html

If it is helpful to do so during development, GitLab and/or GitHub Actions could be involved, but I see no reason why either of them would be relevant to what we end up deploying. Our repositories are hosted on GitHub, and it should be completely sufficient to have GitHub deliver web notifications about pull requests to whatever CI system we develop. As far as I know, Buildbot supports integration with GitHub PRs, and we already use Buildbot for the final builds, so it would make sense to me to use it for CI builds as well, if we're going to spend time developing our own system.


Reply | Threaded
Open this post in threaded view
|

Re: Can we enable CI for legacy systems?

Ruben Di Battista
I don't know Ryan. I find BuildBot pretty involved in the configuration. The interface of Gitlab CI, the one I'm more familiar with, is way easier. To configure a runner it's basically adding a repository on your favorite distro, installing the gitlab-runner package, configuring it with few TOML lines, and that's it. It will happily get your CI/CD jobs. And can be used across multiple projects that might need access to old systems.

In any case I'll try to hack a fast solution at the beginning with that, then we might discuss to use BuildBots.

PS: Gitlab CI can be used also on Github: https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html

On Wed, Jan 27, 2021 at 7:17 PM Ryan Schmidt <[hidden email]> wrote:
On Jan 27, 2021, at 06:32, Mojca Miklavec wrote:

> Maybe GitLab runner isn't able to run on the oldest macOS that we
> support, but if you run it on the host just to fire up a VM, that
> might be ok.
>
> I see that GitLab supports CI on top of GitHub repository:
>    https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html
>
> Maybe that's not as straightforward as if the repo was stored on
> GitLab directly, but it still sounds perfectly fine if you get it
> working.
>
> Even if you just start with your own clone of the GitHub repo inside
> GitLab and get it working, this would still represent some 90 % of the
> job (majority of [a] and complete [c]).
>
>> PS: Does Github Action support custom "executors" to eventually run libvirt?
>
> I'm not so familiar with GitHub Actions, but we are currently using
> buildbot for the official builds. That one certainly offers native
> libvirt support:
>    https://docs.buildbot.net/latest/manual/configuration/workers-libvirt.html

If it is helpful to do so during development, GitLab and/or GitHub Actions could be involved, but I see no reason why either of them would be relevant to what we end up deploying. Our repositories are hosted on GitHub, and it should be completely sufficient to have GitHub deliver web notifications about pull requests to whatever CI system we develop. As far as I know, Buildbot supports integration with GitHub PRs, and we already use Buildbot for the final builds, so it would make sense to me to use it for CI builds as well, if we're going to spend time developing our own system.




--
          _  
-.     .´  |∞∞∞∞
  ',  ;    |∞∞∞∞∞∞
    ˜˜       |∞∞∞∞∞∞∞∞∞ RdB
    ,.,    |∞∞∞∞∞∞
  .'   '.  |∞∞∞∞
-'       `'
https://rdb.is