Jenkins expertise?

[Michał "phoe" Herda]

I have a tiny tiny bit of Jenkins expertise. Not much, but enough for my
own personal use cases.

Last week, I have managed to set up a spare computer with a Jenkins
instance and SBCL/CCL installed on macOS/Linux/Win10 virtual machines,
and got to the point where I can quickload and run ASDF tests on those.
I am thinking of exposing this machine over the Internet soon and
setting it to do daily runs of bleeding edge versions of some Lisp software.

See
https://cdn.discordapp.com/attachments/297478485000192010/764837503345360946/Zrzut_ekranu_z_2020-10-11_15-10-46.png

~phoe

On 14.10.2020 18:09, Robert Goldman wrote:
> Eric,
>
> Thank you very much for this quite helpful, and in depth discussion
> of the issues.  If Jenkins was to be preferable, would it be possible
> to have the Gitlab CI trigger an external Jenkins job? I believe that
> this is possible, because I am working on a large program (hosted on
> someone else's site) where the code is hosted on GitLab, but the tests
> are run on a separate Jenkins server, and the two are integrated using
> Gitlab's pipelines.
>
> Best,
> R
>
>
> On 14 Oct 2020, at 10:50, Eric Timmons wrote:
>
>> https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/146 uses
>> cl.net's shared Gitlab CI runners. It appears that the shared runner can
>> only run one job at a time, so the pipeline that MR introduces takes
>> close to an hour to run (and that's only testing with four
>> implementations). I also suspect no pipelines from other projects were
>> running at the time.
>>
>> If the CLF or someone else can provide additional runners for ASDF's
>> use, that would be a nice way to cut down on pipeline time and avoid
>> impacting other projects.
>>
>> However, as much as I love Gitlab CI, the "core" tier of it (what I
>> /believe/ cl.net runs) does have some limitations that, given my limited
>> Jenkins knowledge, a properly configured Jenkins setup wouldn't have.
>>
>> First, the core tier is unable to test against the merged result of an
>> MR. I don't think that one's a deal breaker as any CI is better than
>> none at all, issues are unlikely if the merge has no conflicts, and any
>> issues would be quickly found after the merge completed (and either
>> fixed or rolled back). Alternatively, ASDF could enforce (via Gitlab)
>> that MRs need to be rebased on to the target branch, effectively making
>> the source branch equivalent to the merged result.
>>
>> The tougher one to work around is caused by the forking model of
>> contributing code. Forks are unable to use their parent's CI runners and
>> the pipelines for MRs from forks are run in the CI context of the
>> fork. So if ASDF has special runners for the licensed implementations
>> they can't be used until the MR is merged. Additionally, the pipelines
>> before merging will be slow as they'll be using the cl.net shared CI
>> runners.
>>
>> There are a couple of ways to deal with the second issue, but they all
>> have their drawbacks. The best way would likely be to pull contributions
>> from forks into a separate branch in the parent repo before merging to
>> master. That would allow any ASDF specific runners to do their job, but
>> would require some extra steps from the maintainers. (And contributors
>> would just have to deal with their jobs running slowly before the
>> merge). I'm sure a sufficiently motivated person could even write a
>> Gitlab CI job that auto merged to master from this testing branch if the
>> tests all pass.
>>
>> -Eric
>>
>> "Robert P. Goldman" <rpgoldman at sift.net> writes:
>>
>>> Thanks for reaching out , Dave. I hadn't realized that cl.net had
>>> the full gitlab CI hooked up to it. Are there any resource issues?
>>> There are a lot of projects hosted there.
>>>
>>> That said, are there sufficient resources there if we start running
>>> a pipeline?
>>>
>>> -- 
>>> Robert P. Goldman
>>>
>>> On October 14, 2020 at 07:21:44, Dave Cooper
>>> (david.cooper at genworks.com(mailto:david.cooper at genworks.com)) wrote:
>>>
>>>>
>>>> Dear Robert,
>>>>
>>>> Are you sure you want to use Jenkins? Gitlab has built-in CI. And
>>>> the CLF has acquired Allegro CL licenses for a ASDF testing
>>>> (graciously donated by Franz Inc), and we have a to-do item to
>>>> attempt the same for LispWorks. If you’re willing, we would like to
>>>> help set up ASDF testing pipelines as part of
>>>> common-lisp.net(http://common-lisp.net) infrastructure.
>>>>
>>>> If you have reasons of your own to set up a Jenkins setup and could
>>>> use access to Allegro and maybe Lispworks licenses for that
>>>> purpose, please reach out regarding that as well. I am not sure
>>>> about any Jenkins experience among clf or cl.net(http://cl.net)
>>>> volunteers, however.
>>>>
>>>> Please advise,
>>>>
>>>> Dave
>>>>
>>>>
>>>>
>>>> On Tue, Oct 13, 2020 at 11:06 PM Robert Goldman
>>>> <rpgoldman at sift.info(mailto:rpgoldman at sift.info)> wrote:
>>>>>
>>>>> Does anyone have expertise configuring Jenkins to run against a
>>>>> remote Gitlab install?
>>>>>
>>>>>
>>>>> If so, would you please reach out to me? I have finally restored
>>>>> some of my CI support for ASDF, but I don't know how to set up my
>>>>> Jenkins to run against merge requests on Gitlab (if that is even
>>>>> possible).
>>>>>
>>>>>
>>>>> I have a backlog of patches that I would like to get evaluated and
>>>>> merged, but could use some help with the automation.
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> My Best,
>>>>
>>>> Dave Cooper, david.cooper at gen.works
>>>> genworks.com(http://genworks.com), gendl.org(http://gendl.org)
>>>> +1 248-330-2979
>>>>
>