Samba on GitLab

From SambaWiki

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 as 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 your GitLab username, 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 gitlab username, and be nice. Use only to develop Samba. 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.

If you describe your work in the branch name, this will make generating a merge request easier, as the branch name becomes the template title and allows ongoing distinct merge requests.

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 a git reference to the gitlab remote repository:

$ git remote add gitlab-ci

Push current HEAD to new remote branch called '$USER-foo' 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. Note that if your gitlab username is different to the username on the local system, the '$USER' name you need to use in the git commands when pushing to gitlab is your *gitlab* username, not your local username.

Push HEAD to existing remote branch called '$USER-foo' on gitlab CI:

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

CI Results

  • CI results for changes are here: Pipelines
  • merge requests show a link to the Pipeline (CI) results for each patch series.

Debugging CI failures

Please see these sub-pages for details on how to debug failures shows up by GitLab CI:

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.

Free CI for forks on

By default a CI pipeline will run for any push to a fork of Samba. Much of the testsuite runs, but not everything, which is why we have the special shared development repository.

1 hour Timeout

By default projects on have a 1 hour timeout set on pipelines. This can be changed in the project settings.

We suggest using a timeout of 3 hours, which is still permitted on the free runners.

Creating a merge request

If you pushed your patch to a unique well-named branch (above), then it is really easy to submit the change for inclusion in Samba.

When you pushed your branch, a link will have been printed to create a merge request. Click that. If no link is printed it may be due to a complex ssh configuration. Don't panic, you can still create a merge request using the following section.

To do it later, navigate to your branch on gitlab, eg$USER-foo and click 'Create Merge Request'.

This will trigger an e-mail to Samba developers registered on GitLab suggesting that your code should be merged. You may wish to also mail the patch or merge request URL to samba-technical for additional attention.

Further pushes to the same branch will then update the merge request, start a fresh CI run and re-send notifications, so the current code and test status is always available.

For this reason choose a unique branch name per patch series, and do not reuse the branch name until the merge request has been closed.

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 with a message like:

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

See for example this closed merge request.

Getting help

If something isn't working, or you need help, the first port of call should be the samba-technical mailing list. Service Status

GitLab Support

Don't panic

Finally, in the immortal words of Douglas Adams: Don't Panic

As a toolchain, git is a decentralised version control system. While a service outage would certainly be inconvenient, development work can continue locally through an outage.