qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/2] GitLab Gating CI: initial set of jobs, documentation


From: Cleber Rosa
Subject: Re: [PATCH v2 2/2] GitLab Gating CI: initial set of jobs, documentation and scripts
Date: Fri, 4 Sep 2020 10:27:27 -0400

On Fri, Sep 04, 2020 at 11:11:25AM +0200, Andrea Bolognani wrote:
> On Thu, 2020-09-03 at 17:12 -0400, Cleber Rosa wrote:
> > On Thu, Jul 09, 2020 at 10:55:07AM +0200, Erik Skultety wrote:
> > > On Wed, Jul 08, 2020 at 10:46:57PM -0400, Cleber Rosa wrote:
> > > > +.. note:: there are currently limitations to gitlab-runner itself when
> > > > +          setting up a service under FreeBSD systems.  You will need to
> > > > +          perform steps 4 to 10 manually, as described at
> > > > +          https://docs.gitlab.com/runner/install/freebsd.html
> > > 
> > > What kinds of limitations? Is it architecture constrained maybe? I'm 
> > > asking
> > > because we have all of the steps covered by an Ansible playbook, so I 
> > > kinda got
> > > triggered by the word "manually". Also, the document only mentions 9 steps
> > > overall.
> > 
> > FreeBSD's "service management" (systemd/sys-v like) is not covered by
> > the GO library[1] used on gitlab-runner.  It's not ideal, and the
> > second best solution would be to script the equivalent handling within
> > the playbook, but I remember trying and finding some inconsistencies.
> > Then, I had to give it up and defer to whenever a FreeBSD job is
> > actually added.
> > 
> > [1] - https://github.com/ayufan/golang-kardianos-service
> 
> Note that this is a fork of
> 
>   https://github.com/kardianos/service
> 
> where FreeBSD support was added recently with
> 
>   
> https://github.com/kardianos/service/commit/14b2cc59a290407a6f1cb3daba59069429d9665b
>

That's good news!

> I'm not sure why gitlab-runner would use a fork rather than the
> primary repository, but perhaps they can be convinced to switch and
> gain better FreeBSD support in the process.
>

I can only imagine they were using the fork because the primary
repository did not have the bits they needed there... and were not
willing or were not successful and getting them there.

We can ask/hope/wait for gitlab to switch, and then this will no
longer be an issue indeed.

Thanks,
- Cleber.

> -- 
> Andrea Bolognani / Red Hat / Virtualization
> 

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]