Summary

This setup is for a virtual machine running Ubuntu 64bit (15.10, headless) in conjunction with the cloud version of gitlab using their free ‘coordinator’. The virtual machine is behind a firewall and runs on a host with VM-Workstation Player 12 running Ubuntu 64bit (12.04, headless).

This also covers the installation on Windows 7 64bit for a single user GUI mode that allows the gitlab-runner access to start GUI software for build or test pipelines.

Software Required

  • VMware-Player-12.1.1-3770994.x86_64.bundle
  • VMware-VIX-1.15.0-2985596.x86_64.bundle
  • VMware-VIX-1.15.3-3770994.x86_64.bundle
  • Git (or Git-Bash for Windows)

Steps

1. Install Gitlab Runner on the VM

Linux

From the instructions on gitlab.com, run the following commands:

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
sudo apt-get install gitlab-ci-multi-runner
sudo gitlab-ci-multi-runner register

The runner registration info can be found on under the ‘runners’ tab from in the desired project:

https://gitlab.com/<group>/<repo>/runners

The ‘Shared runners’ option was disabled since they likely don’t have the specific requirements for this build, which are maintained internally.

This basically says to enter the free CI ‘coordinator’ URL:

Specify the following URL during runner setup: 
https://gitlab.com/ci

Use the following registration token during setup:

<some alpha numeric token to copy and paste>

The next questions are for identification of the runner (from the web interface) and some tags that explain what the runner is good for. In this case, its for a GPI node compilation:

Please enter the gitlab-ci description for this runner:
[gpilab]: ubuntu64
Please enter the gitlab-ci tags for this runner (comma separated):
gpi,python3

Since the compilation is not very complicated I assumed a shell environment would be sufficient for this -since I hadn’t built the script yet.

Please enter the executor: ssh, virtualbox, docker+machine, docker-ssh+machine, docker, docker-ssh, parallels, shell:
shell

...

The runner should be auto-started.

This can be verified with:

ps aux | grep gitlab-runner

Which returns something like:

root      4355  0.1  0.3  60016 13352 ?        Ssl  10:45   0:01 /usr/bin/gitlab-ci-multi-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner

Windows

The gitlab-ci-multi-runner command can install itself as a service, however, this service will be unable to access UI elements. If those are necessary for say testing pipelines, then you’ll have to set the gitlab-runner to launch as a scheduled task (see gitlab issue 1046).

The following steps where modified from some sage install guide:

  • Navigate to Start » Control Panel » Administrative Tools » Task Scheduler
  • Click on Task Scheduler » Create Task option
General Tab:
    Name: gitlab_runner_startup
    Run only When user is logged in: x
    Run with the highest privileges: x
    Configure For: <your windows version>
  • Then navigate to Action tab and select New.
  • ‘New Action’ UI will get opened.
  • In ‘Program/Script’ select the gitlab-runner ‘EXE’ file, for that you want to run using ‘Browse’ button.
  • In ‘Add arguments (optional)’ field, enter run
  • In the “Start in (optional)” field, enter the path that holds the config.toml file that was used to setup the runner.
  • Click on OK » ‘New Action’ UI will get closed.
  • Now, navigate to Triggers Tab » New » ‘New Trigger’; an UI will get opened.
    Begin the task: At log on
    Specific user: <your intended user>
    Delay task for: <whatever time your extra components need to boot>
    Enabled: x
  • Make sure the selected user is going to be auto-logged in.
  • Also check that the AutoLoginCount is set to a large number .
  • Click on OK » New Trigger UI will get closed.
  • Now click on OK button in ‘Create Task’ UI.
Save the Schedule as an XML File
  • Find the gitlab_runner_startup task in the ‘Active Tasks’ section and double click it. This will open the ‘Actions’ menu to the right.
  • Click on the ‘Export’ feature to save the scheduled task for porting to other VMs or as a backup.
  • Click ‘Run’ to test your task.

2. Add the .gitlab-ci.yml to the Project Repo

On the project homepage click the ‘Set Up CI’ button to add a template .gitlab-ci.yml file to the root directory of the project. For this, I chose the Nanoc template since it seemed like a good start.

Changed the job name to the GPI node that was being built and pointed the script: tag to the packaging script that is contained in the root dir of the repo with reference to the GitLab Runner Docs. Switched artifacts to \*.zip and the correct build branch.

After commiting the yaml file, I opened the ‘Pipelines’ to find that the yaml was invalid due to some unrecognized character. Using the yaml validator at https://gitlab.com/ci/lint I was able to determine that file globbing must be done with a regex /^\*.zip$/.

3. Add ssh Keys

You’ll need to use what GitLab refers to as a “deploy key” which allows read only access to a specific project.