<div dir="auto">I was wondering... Would à Linux machine with some virtualization method (libvirt?) be acceptable as CI runner? Any of you has experience in terms of performance? <div dir="auto"><br></div><div dir="auto">Also, Gitlab CI allows to attach personal runners to project very easily (just a package to install from the os package manager) . How does it work for Github? </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 7 Sep 2020, 15:50 Mojca Miklavec, <<a href="mailto:mojca@macports.org">mojca@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 7 Sep 2020 at 10:46, Ralph Seichter wrote:<br>
><br>
> I fail to remember the last time one of my builds successfully passed<br>
> Travis CI. All I see are timeouts [1]. Other peoples' jobs apparently<br>
> make it through Travis OK, so I wander what I can do to increase my<br>
> chances?<br>
<br>
By far the best thing would be to implement the functionality that<br>
would allow firing up a clean VM, do the build, close the VM & destroy<br>
it, and run this on our own buildbot workers.<br>
<br>
This requires both manpower to implement the functionality as well as<br>
additional hardware resources to run the builds.<br>
If we solve the first part, I guess we should be able to solve the<br>
second one as well.<br>
If you volunteer to do some research / work in this area ... that<br>
would likely be the most significant step in "increasing your chances"<br>
... probably up to 100% for the ports that have no chance in building<br>
in < 50 minutes on a super slow hardware owned by Travis :)<br>
<br>
Mojca<br>
</blockquote></div>