Samba CI resources

Andrew Bartlett abartlet at
Wed Sep 23 04:56:43 UTC 2020

Samba uses a lot of CI, and the number of CPU hours consumed has
increased drastically over the past few years.

This has made an awesome positive change to Samba.  While time spent in
CI has a real cost, so is engineer time wasted looking at patches that
are not ready yet.

However, every CPU hour spent in CI is a real CPU - the cloud is just
somebody else's computer after all.

When we started with GitLab CI, we took about 4-5 CPU hours.  With all
the parallel builds we get back an answer in 1 hour, but we now take 20
CPU hours to do it.

I would like the team to think of is ways to reduce our CI.

Towards that I have two MRs pending review:

I would also ask that we all think really carefully before adding one
more build job or supported distribution (as those run a samba-o3
task).  Each job really costs someone, be it the team, who
provide much to us without charge, or the planet warmed by the waste
heat and the energy input.

I would also ask for other ideas to reduce duplicated testing.  I know
David is trying to do that - removing duplicate smbtorture3 tests - but
that got a bit stuck (it is really hard work).  I do wonder if we could
reduce how much of our testsuite needs to be duplicated for the MIT
build for example.

I also think we should also reduce, or at least not increase, the
number of supported build combinations.  We try hard to test Samba in
all the build combinations we support, but each of these has a very
real cost.  

For example, while we can't unscramble the egg that leads us to having
to support MIT krb5, lorikeet-Heimdal and system heimdal, but we should
try hard not to do that again and take my MR 1568 to take out the py2

Finally, if you are just doing a 'push to save' on a WIP branch, add '-
o ci.skip' to save a CI run.


Andrew Bartlett

Andrew Bartlett             
Authentication Developer, Samba Team
Samba Developer, Catalyst IT 

More information about the samba-technical mailing list