| Jobs on Custom Runners | 
 | ====================== | 
 |  | 
 | Besides the jobs run under the various CI systems listed before, there | 
 | are a number additional jobs that will run before an actual merge. | 
 | These use the same GitLab CI's service/framework already used for all | 
 | other GitLab based CI jobs, but rely on additional systems, not the | 
 | ones provided by GitLab as "shared runners". | 
 |  | 
 | The architecture of GitLab's CI service allows different machines to | 
 | be set up with GitLab's "agent", called gitlab-runner, which will take | 
 | care of running jobs created by events such as a push to a branch. | 
 | Here, the combination of a machine, properly configured with GitLab's | 
 | gitlab-runner, is called a "custom runner". | 
 |  | 
 | The GitLab CI jobs definition for the custom runners are located under:: | 
 |  | 
 |   .gitlab-ci.d/custom-runners.yml | 
 |  | 
 | Custom runners entail custom machines.  To see a list of the machines | 
 | currently deployed in the QEMU GitLab CI and their maintainers, please | 
 | refer to the QEMU `wiki <https://wiki.qemu.org/AdminContacts>`__. | 
 |  | 
 | Machine Setup Howto | 
 | ------------------- | 
 |  | 
 | For all Linux based systems, the setup can be mostly automated by the | 
 | execution of two Ansible playbooks.  Create an ``inventory`` file | 
 | under ``scripts/ci/setup``, such as this:: | 
 |  | 
 |   fully.qualified.domain | 
 |   other.machine.hostname | 
 |  | 
 | You may need to set some variables in the inventory file itself.  One | 
 | very common need is to tell Ansible to use a Python 3 interpreter on | 
 | those hosts.  This would look like:: | 
 |  | 
 |   fully.qualified.domain ansible_python_interpreter=/usr/bin/python3 | 
 |   other.machine.hostname ansible_python_interpreter=/usr/bin/python3 | 
 |  | 
 | Build environment | 
 | ~~~~~~~~~~~~~~~~~ | 
 |  | 
 | The ``scripts/ci/setup/build-environment.yml`` Ansible playbook will | 
 | set up machines with the environment needed to perform builds and run | 
 | QEMU tests.  This playbook consists on the installation of various | 
 | required packages (and a general package update while at it).  It | 
 | currently covers a number of different Linux distributions, but it can | 
 | be expanded to cover other systems. | 
 |  | 
 | The minimum required version of Ansible successfully tested in this | 
 | playbook is 2.8.0 (a version check is embedded within the playbook | 
 | itself).  To run the playbook, execute:: | 
 |  | 
 |   cd scripts/ci/setup | 
 |   ansible-playbook -i inventory build-environment.yml | 
 |  | 
 | Please note that most of the tasks in the playbook require superuser | 
 | privileges, such as those from the ``root`` account or those obtained | 
 | by ``sudo``.  If necessary, please refer to ``ansible-playbook`` | 
 | options such as ``--become``, ``--become-method``, ``--become-user`` | 
 | and ``--ask-become-pass``. | 
 |  | 
 | gitlab-runner setup and registration | 
 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 
 |  | 
 | The gitlab-runner agent needs to be installed on each machine that | 
 | will run jobs.  The association between a machine and a GitLab project | 
 | happens with a registration token.  To find the registration token for | 
 | your repository/project, navigate on GitLab's web UI to: | 
 |  | 
 |  * Settings (the gears-like icon at the bottom of the left hand side | 
 |    vertical toolbar), then | 
 |  * CI/CD, then | 
 |  * Runners, and click on the "Expand" button, then | 
 |  * Under "Set up a specific Runner manually", look for the value under | 
 |    "And this registration token:" | 
 |  | 
 | Copy the ``scripts/ci/setup/vars.yml.template`` file to | 
 | ``scripts/ci/setup/vars.yml``.  Then, set the | 
 | ``gitlab_runner_registration_token`` variable to the value obtained | 
 | earlier. | 
 |  | 
 | To run the playbook, execute:: | 
 |  | 
 |   cd scripts/ci/setup | 
 |   ansible-playbook -i inventory gitlab-runner.yml | 
 |  | 
 | Following the registration, it's necessary to configure the runner tags, | 
 | and optionally other configurations on the GitLab UI.  Navigate to: | 
 |  | 
 |  * Settings (the gears like icon), then | 
 |  * CI/CD, then | 
 |  * Runners, and click on the "Expand" button, then | 
 |  * "Runners activated for this project", then | 
 |  * Click on the "Edit" icon (next to the "Lock" Icon) | 
 |  | 
 | Tags are very important as they are used to route specific jobs to | 
 | specific types of runners, so it's a good idea to double check that | 
 | the automatically created tags are consistent with the OS and | 
 | architecture.  For instance, an Ubuntu 20.04 aarch64 system should | 
 | have tags set as:: | 
 |  | 
 |   ubuntu_20.04,aarch64 | 
 |  | 
 | Because the job definition at ``.gitlab-ci.d/custom-runners.yml`` | 
 | would contain:: | 
 |  | 
 |   ubuntu-20.04-aarch64-all: | 
 |    tags: | 
 |    - ubuntu_20.04 | 
 |    - aarch64 | 
 |  | 
 | It's also recommended to: | 
 |  | 
 |  * increase the "Maximum job timeout" to something like ``2h`` | 
 |  * give it a better Description |