Difference between revisions of "Samba CI on gitlab/Under the hood"

(Created page with "=How GitLab CI works at a High Level= ==Running remote scripts, displaying the output== Like the Samba build farm of old, GitLab CI is best seen as a system for running scri...")
 
m (Running remote scripts, displaying the output)
Line 7: Line 7:
 
In Samba's case, the remote script is '''[[autobuild.py]]''' plus some housekeeping before and after.  The details is recorded in the '''.gitlab-ci-private'''
 
In Samba's case, the remote script is '''[[autobuild.py]]''' plus some housekeeping before and after.  The details is recorded in the '''.gitlab-ci-private'''
  
===.gitlab-ci-private.yml vs .gitlab-ci.yml
+
===.gitlab-ci-private.yml vs .gitlab-ci.yml===
  
 
We have two different CI configurations, one using the default name (so picked up by default by forks of our repo) and one that we specify in the [[Samba CI on gitlab#Where is the Samba CI repo on GitLab?|Common development repo]]
 
We have two different CI configurations, one using the default name (so picked up by default by forks of our repo) and one that we specify in the [[Samba CI on gitlab#Where is the Samba CI repo on GitLab?|Common development repo]]

Revision as of 20:41, 12 February 2019

How GitLab CI works at a High Level

Running remote scripts, displaying the output

Like the Samba build farm of old, GitLab CI is best seen as a system for running scripts on remote hosts against a git checkout.

In Samba's case, the remote script is autobuild.py plus some housekeeping before and after. The details is recorded in the .gitlab-ci-private

.gitlab-ci-private.yml vs .gitlab-ci.yml

We have two different CI configurations, one using the default name (so picked up by default by forks of our repo) and one that we specify in the Common development repo

Wrapping docker

To get a consistent build environment docker images are used, so the scripts runs in a docker container. The image used is defined in the .gitlab-ci.yml file.

On a private VM

To allow us to accept and test code from a broader range of contributors, and to enable scaling at times of peak load, the docker container is started in a private VM using Docker Machine]. This applies for both the private and shared (provided by gitlab.com) runners.