Extending Gitlab CI

Andrew Bartlett abartlet at samba.org
Fri Dec 14 08:00:23 UTC 2018

On Fri, 2018-12-14 at 08:22 +0100, Andreas Schneider wrote:
> On Thursday, 13 December 2018 18:59:15 CET Andrew Bartlett wrote:
> > Additionally, see
> > https://gitlab.com/samba-team/samba/merge_requests/152
> > for a very interesting approach, have autobuild.py (as run on sn-devel)
> > push to a GitLab and have the tests run remotely!
> > 
> > That would both reduce server load and make it much easier to update
> > our dependencies, as it just becomes a matter of updating docker files!
> > 
> > In short, this is exactly the direction we should be going.
> I've discussed something similar with Metze. However we thought about directly 
> talking to gitlab CI runners.
> python-glitlab only talks to gitlab and not runners. 

I don't think you would want to talk directly to runners.  We should
try and re-use as much of GitLab as we can, rather than building
bespoke stuff.

GitLab provides as better UI for following the job and allows
restarting a failed job.  Imagine restarting just (eg from the failure
I just got, samba-nt4) and not having to try your luck again with ctdb
or our replication tests!  (Not that there is an excuse for flapping
tests, but for now they are a reality). 

> I guess autobuild could 
> also push to gitlab to trigger builds.

That is what this script does, pushes a tree and follows the build.  

Pretty simple actually, I've not yet tried it but I saw it work for

Allowing the different release streams to build on different hosts
could be really helpful, so we don't have to port Samba 4.7 to pass a
full autobuild on Ubuntu 18.04's modern gcc with -O3 would be a major

(Older releases would just declare an older docker image).

Andrew Bartlett

Andrew Bartlett
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   

More information about the samba-technical mailing list