Jenkins expertise?

[Eric Timmons]

I think I'm in the same boat as you, unfortunately. I know it's possible
to integrate Jenkins and Gitlab, but I've never set it up myself. A
brief search seems to indicate that the Gitlab sanctioned way of doing
it is not available in Core
(https://docs.gitlab.com/ee/integration/jenkins.html). It looks like
there are Jenkins plugins to do it
(https://plugins.jenkins.io/gitlab-plugin/), but I don't use Jenkins and
have zero way of evaluating the quality.

If you decide to use Gitlab CI with ASDF specific runners for the
licensed implementations, I'd recommend giving regular contributors
Developer access to the ASDF repo. This would let the people that are
most likely going to be impacted by slow test times and lack of licensed
implementations the ability to use the ASDF runners by doing all their
work in the parent repo. The master branch can then be protected (if it
isn't already) and configured to not allow Developers to push to it, so
that MRs are still required.

Infrequent or one off contributors would just have to deal with the slow
test times and someone with Developer rights would have to merge to some
temporary branch to test the licensed implementations before merging to
master.

-Eric

"Robert Goldman" <rpgoldman at sift.info> writes:

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