Samba on GitLab

From SambaWiki
Revision as of 09:31, 16 October 2018 by Abartlet (talk | contribs) (explain how to debug failures)

Samba has a GitLab mirror of the official git repository used to aid development

Where is the Samba CI repo on GitLab?

Getting Access

Samba Team members

Samba Team members are encouraged to join the Samba Team organisation here:

Just ask on the team list from your team e-mail with your gitlab username.

A fellow team member with Maintainer rights can then add you a Developer via this page:

Other Samba developers

Our broader developer community is encouraged to apply to use the Samba CI repo. Access is given to folks active on the mailing list with patches to submit, not just to Samba Team members.

Please write a mail to with details of your contribution history or plans and a Samba Team member with Maintainer rights can then add you as a Developer via this page:

Triggering CI

The git remote URL for the Samba CI repo is

A CI run is triggered after every push. This makes it easy to find issues early.

Code of conduct

Please prefix branches with your username, and be nice. Don't overwrite the work of others.

In return you get a full CI run using Samba Team provided resources running thanks to a credit in Rackspace's cloud. That in turn makes it easier for Samba Team members doing Code Review as your patches will work first time, and they can see proof of that.

Step by step instructions

Here are the basics steps for Samba team members (and others who have been granted access) to start from scratch.

Add remote:

$ git remote add gitlab-ci

Push current HEAD to new remote branch on gitlab CI:

$ echo $USER
$ git push gitlab-ci +HEAD:refs/heads/$USER-foo

See the Code of Conduct for an explanation of the usage of the username from the USER environment variable.

Push HEAD to existing remote branch on gitlab CI:

$ git push gitlab-ci +HEAD:$USER-foo

CI Results

CI results are here: Pipelines

Debugging CI failures

In docker

Install docker and run:

docker run -ti /bin/bash

Then you need to clone the samba git repository with your changes and run the test.

You can find how to run it in the log of the failed pipeline.

make test

Many issues shown up in CI reproduce without difficulty by running the individual test.

This can be either inside the docker container (which has the reference set of packages) or on your development system for more generic issues

Build Samba with

./configure --enable-developer
make -j

And run the test with

make test TESTS=mytest

Points to note

Resource limitations

The 'private' runners are 4 CPU virtual machines with 8GB of ram. These run in Rackspace's cloud and are paid for from a credit with RackSpace by the Samba Team.

The 'shared' runners are 1 CPU virtual machines with 4GB of RAM. The name is a misnomer, they are not shared VMs, but access to the newly booked VMs is shared to us (and paid for) by

Some tests fail or flap on GitLab CI due to resource limitations. This can cause

  • Docker failure code 137 (likely a kill -9 due to the out of memory killer running)
  • Tests failure because they do not run fast enough (timeouts or failures due to timing)
  • Race conditions (AD schema and DRS replication are particularly prone to this)

Tests should be re-worked to be more memory efficient, more robust to poor CPU scheduling and race-free, but in the meantime this is worth being aware of.

Long hostnames

sn-devel is a nice short hostname, so is laptop etc. Specifically they are less than 14 characters, so do not need to be truncated.

Due to the way the GitLab CI instances are booted under docker, they get long hostnames like runner-191a8437-project-6378020-concurrent-0, which sometimes cause difficult to diagnose issues if not always overridden in the test.

CI for personal GitLab forks

Instructions how to run CI with your own GitLab runner can be found here: CI using Your own gitlab runner.

This is helpful if you do not wish to share the repository with others (you have your own fork on gitlab). However it requires your own build resources.

Merging patches from GitLab (for Samba Team members)

If the developer has created a merge request, then to merge, download the patch with (eg)

Add review tags and then 'git autobuild' locally. The merge button sadly doesn't work.

Then when the patch is in's git master close the merge request a message like:

Merged into master as <git hash> for Samba <next version>.

See for example this closed merge request.