Re: Jenkins expertise?
Michał "phoe" Herda <[email protected]>
| Newsgroups | gmane.lisp.common-lisp-net.devel |
|---|---|
| Message-ID | <[email protected]> |
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" <[email protected]> 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 >>> ([email protected](mailto:[email protected])) 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 >>>> <[email protected](mailto:[email protected])> 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, [email protected] >>>> genworks.com(http://genworks.com), gendl.org(http://gendl.org) >>>> +1 248-330-2979 >>>> >