An even better GitLab CI (was: Re: Document GitLab as the only way to contribute to Samba?)

[Michael Adam]

On 2019-06-29 at 08:29 +1200, Andrew Bartlett wrote:
> On Fri, 2019-06-28 at 14:40 +0200, Michael Adam wrote:
> > On 2019-06-28 at 15:08 +0300, Uri Simchoni via samba-technical wrote:
> > > On 6/28/19 2:46 PM, Michael Adam via samba-technical wrote:
> > > > Ugh. That's really strange. Is this a gitlab design choice?
> > > > Because if it is, it's finally a thing (and quite a major one),
> > > > where gitlab is way worse than github. ;-)
> > > > 
> > > 
> > > To be fair, I don't know if GitHub even has CI. What I've seen in  FLOSS
> > > projects is that they have their Jenkins/Travis instance or something of
> > > that sort (and who knows how many runners), and each PR would trigger a
> > > run there, and success/failure would annotate the PR. GitHub just
> > > provides the webhook.
> > 
> > That is true. CI is always external.
> > But you typically configure the repo to require those CIs passing
> > for a PR to become merge-able.
> > 
> > > I do agree with the bottom line though...
> > 
> > And don't get me wrong: I'm not advocating for github here.
> > I was just comparing with something I know better.
> > And if we could somehow tie the beefier CI with the core repo
> > and run it on every MR, that would be great.
> > But I probably need to read up on gitlab and it's ci etc.
> 
> When we used Travis CI on GitHub we did the same thing, except we never
> had the full set of tests, it was always a cut down set.
> 
> It started as just a compile and very few tests, but enough to catch
> the typical python whitespace errors and mixups between docs and
> loadparm.  Just before we killed it we got it similar to the 'shared'
> set on GitLab (I had to tweak it hard to get the run under an hour
> total). 

Sure, Travis CI is too weak for full tests.
One project I have been working on is

https://github.com/heketi/heketi

(Just as background and for context: This is some kind of high
level service interface on top of gluster we use with it's
restful API for volume self-service in kubernetes.)

Here you can see that we are running Travis CI jobs automatically
for each PR. And it's mandatory for them to pass for being able
to merge. But the interesting bit is "centos-ci". This is a set
of resources donated (in this case, to the gluster project) by
the centos project with jenkins and all where we can run full
integration tests with a couple of VMs etc. So we have integrated
this centos-ci for the heketi project to set up a 4-node libvirt
cluster with vagrant to run functional/integration tests.
But (here it gets interesting): we don't run them unconditionally
for each PR, but a team member has to do a magic incantation in
a comment in the PR to trigger this run. This works quite well,
and you can make these tests optional or mandatory for being able
to merge. We have the full control over what we run and how long
it may run.

> I'm also kind of glad the CI is attached to the repo in one sense only:
> The private runners are (after credits) at the Samba Team's cost. 
> Abuse of free CI runners is a real thing, and so I'm more comfortable
> with the risk when we can manually vet/ban users.

Understood. This is a very valid argument, too!

> The fix is to:
>  - Reduce the time spent in each job by:
>   - use the pipeline feature in GitLab more to split the compile into a
> different job
>   - passing the compiled output (or primed ccache cache) to the 'test'
> runners.  
> 
>  - Remove the dependency on an ext4 file system in our SMB tests or
> find a way to get to ext4 on the shared runners (and not unionfs)
> 
>  - Reduce further the resource use of our tests
>   - shut down smbd/samba processes when we are done with them in
> selftest.pl
>   - optimise the memory use of smbd/samba even more
> 
> All very much practical tasks, we just need help.  I'm always available
> to consult, but I can't take on this much myself.  It would suit a
> (new?) enthusiastic developer who is keen to make a mark and is willing
> to streach the boundaries and try the 'impossible' to prove it isn't
> really.

Just (thinking out of the current gitlab-ci) box (but inside my
area of experience): Is it possible to add some other CI runs in
gitlabl that would trigger via some web-hooks? Those could be
used for real cluster tests with multiple VMs, or tests that have
other special requirements that the free CI runners can not
satisfy (like ext4 ...). Alternatively, could we integrate other
external runners with the existing CI?
Just checking the conceptual possibilities.
(Maybe we need to have a video call and you can walk me thorough
how it is working in the backend, Andrew, so I can understand
better...)

Cheers - Michael


> Thanks,
> 
> Andrew Bartlett
> -- 
> Andrew Bartlett                       http://samba.org/~abartlet/
> Authentication Developer, Samba Team  http://samba.org
> Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20190628/c3523d81/signature.sig>