<div dir="ltr"><div>Hi,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 14, 2020 at 5:51 PM Eric Timmons <<a href="mailto:etimmons@mit.edu">etimmons@mit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/146" rel="noreferrer" target="_blank">https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/146</a> uses<br>
<a href="http://cl.net" rel="noreferrer" target="_blank">cl.net</a>'s shared Gitlab CI runners. It appears that the shared runner can<br>
only run one job at a time, so the pipeline that MR introduces takes<br>
close to an hour to run (and that's only testing with four<br>
implementations). I also suspect no pipelines from other projects were<br>
running at the time.<br></blockquote><div><br></div><div>I've increased the number of jobs this runner can run concurrently to 3, because the VM currently has 3 cores configured. If we need to configure more, let me know and I'll have a look at it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If the CLF or someone else can provide additional runners for ASDF's<br>
use, that would be a nice way to cut down on pipeline time and avoid<br>
impacting other projects.<br></blockquote><div><br></div><div>There is also a machine provisioned for cl-test-grid. It's idle often, just not when a new Quicklisp release has been released. If cl-test-grid could be driven by GitLab CI, it would be easy to share the resources this machine has to spare. In that case, I think 2 extra cores would be available for running tests. It would be even better if others would step up to donate their cores.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
However, as much as I love Gitlab CI, the "core" tier of it (what I<br>
/believe/ <a href="http://cl.net" rel="noreferrer" target="_blank">cl.net</a> runs) does have some limitations that, given my limited<br>
Jenkins knowledge, a properly configured Jenkins setup wouldn't have.<br>
<br>
First, the core tier is unable to test against the merged result of an<br>
MR.</blockquote><div><br></div><div>I'm not sure what you mean by this. Do you mean that the CI wouldn't run tests/builds on the master branch after merging an MR?</div><div><br></div><div>What I do know that works: The current <a href="http://common-lisp.net">common-lisp.net</a> site is being built after each merge to the master branch of that repository and the artifacts of the build used to publish the site.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I don't think that one's a deal breaker as any CI is better than<br>
none at all, issues are unlikely if the merge has no conflicts, and any<br>
issues would be quickly found after the merge completed (and either<br>
fixed or rolled back). Alternatively, ASDF could enforce (via Gitlab)<br>
that MRs need to be rebased on to the target branch, effectively making<br>
the source branch equivalent to the merged result.<br>
<br>
The tougher one to work around is caused by the forking model of<br>
contributing code. Forks are unable to use their parent's CI runners and<br>
the pipelines for MRs from forks are run in the CI context of the<br>
fork. So if ASDF has special runners for the licensed implementations<br>
they can't be used until the MR is merged. Additionally, the pipelines<br>
before merging will be slow as they'll be using the <a href="http://cl.net" rel="noreferrer" target="_blank">cl.net</a> shared CI<br>
runners.<br></blockquote><div><br></div><div>If we can disable artifacts on the ASDF runners, we might be able to use a somewhat more liberal assignment of runners to project members: if the artifacts can't be extracted, the options for abuse will become more limited. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There are a couple of ways to deal with the second issue, but they all<br>
have their drawbacks. The best way would likely be to pull contributions<br>
from forks into a separate branch in the parent repo before merging to<br>
master. That would allow any ASDF specific runners to do their job, but<br>
would require some extra steps from the maintainers. (And contributors<br>
would just have to deal with their jobs running slowly before the<br>
merge). I'm sure a sufficiently motivated person could even write a<br>
Gitlab CI job that auto merged to master from this testing branch if the<br>
tests all pass.<br></blockquote><div><br></div><div><br></div><div>That would work too. Let me know what more we can research or I can help with to help solve this issue.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-Eric<br></blockquote><div><br></div><div>Regards,</div><div><br></div><div>Erik.</div></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Bye,<div><br></div><div>Erik.</div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.</div><div>Robust and Flexible. No vendor lock-in.</div></div></div></div>