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
Daniel.
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
advantage.
(Older releases would just declare an older docker image).
Andrew Bartlett
--
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT
https://catalyst.net.nz/services/samba
More information about the samba-technical
mailing list