ci-runners.rst.inc 4.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116
  1. Jobs on Custom Runners
  2. ======================
  3. Besides the jobs run under the various CI systems listed before, there
  4. are a number additional jobs that will run before an actual merge.
  5. These use the same GitLab CI's service/framework already used for all
  6. other GitLab based CI jobs, but rely on additional systems, not the
  7. ones provided by GitLab as "shared runners".
  8. The architecture of GitLab's CI service allows different machines to
  9. be set up with GitLab's "agent", called gitlab-runner, which will take
  10. care of running jobs created by events such as a push to a branch.
  11. Here, the combination of a machine, properly configured with GitLab's
  12. gitlab-runner, is called a "custom runner".
  13. The GitLab CI jobs definition for the custom runners are located under::
  14. .gitlab-ci.d/custom-runners.yml
  15. Custom runners entail custom machines. To see a list of the machines
  16. currently deployed in the QEMU GitLab CI and their maintainers, please
  17. refer to the QEMU `wiki <https://wiki.qemu.org/AdminContacts>`__.
  18. Machine Setup Howto
  19. -------------------
  20. For all Linux based systems, the setup can be mostly automated by the
  21. execution of two Ansible playbooks. Create an ``inventory`` file
  22. under ``scripts/ci/setup``, such as this::
  23. fully.qualified.domain
  24. other.machine.hostname
  25. You may need to set some variables in the inventory file itself. One
  26. very common need is to tell Ansible to use a Python 3 interpreter on
  27. those hosts. This would look like::
  28. fully.qualified.domain ansible_python_interpreter=/usr/bin/python3
  29. other.machine.hostname ansible_python_interpreter=/usr/bin/python3
  30. Build environment
  31. ~~~~~~~~~~~~~~~~~
  32. The ``scripts/ci/setup/$DISTRO/build-environment.yml`` Ansible
  33. playbook will set up machines with the environment needed to perform
  34. builds and run QEMU tests. This playbook consists on the installation
  35. of various required packages (and a general package update while at
  36. it).
  37. The minimum required version of Ansible successfully tested in this
  38. playbook is 2.8.0 (a version check is embedded within the playbook
  39. itself). To run the playbook, execute::
  40. cd scripts/ci/setup
  41. ansible-playbook -i inventory $DISTRO/build-environment.yml
  42. Please note that most of the tasks in the playbook require superuser
  43. privileges, such as those from the ``root`` account or those obtained
  44. by ``sudo``. If necessary, please refer to ``ansible-playbook``
  45. options such as ``--become``, ``--become-method``, ``--become-user``
  46. and ``--ask-become-pass``.
  47. gitlab-runner setup and registration
  48. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  49. The gitlab-runner agent needs to be installed on each machine that
  50. will run jobs. The association between a machine and a GitLab project
  51. happens with a registration token. To find the registration token for
  52. your repository/project, navigate on GitLab's web UI to:
  53. * Settings (the gears-like icon at the bottom of the left hand side
  54. vertical toolbar), then
  55. * CI/CD, then
  56. * Runners, and click on the "Expand" button, then
  57. * Under "Set up a specific Runner manually", look for the value under
  58. "And this registration token:"
  59. Copy the ``scripts/ci/setup/vars.yml.template`` file to
  60. ``scripts/ci/setup/vars.yml``. Then, set the
  61. ``gitlab_runner_registration_token`` variable to the value obtained
  62. earlier.
  63. To run the playbook, execute::
  64. cd scripts/ci/setup
  65. ansible-playbook -i inventory gitlab-runner.yml
  66. Following the registration, it's necessary to configure the runner tags,
  67. and optionally other configurations on the GitLab UI. Navigate to:
  68. * Settings (the gears like icon), then
  69. * CI/CD, then
  70. * Runners, and click on the "Expand" button, then
  71. * "Runners activated for this project", then
  72. * Click on the "Edit" icon (next to the "Lock" Icon)
  73. Tags are very important as they are used to route specific jobs to
  74. specific types of runners, so it's a good idea to double check that
  75. the automatically created tags are consistent with the OS and
  76. architecture. For instance, an Ubuntu 20.04 aarch64 system should
  77. have tags set as::
  78. ubuntu_20.04,aarch64
  79. Because the job definition at ``.gitlab-ci.d/custom-runners.yml``
  80. would contain::
  81. ubuntu-20.04-aarch64-all:
  82. tags:
  83. - ubuntu_20.04
  84. - aarch64
  85. It's also recommended to:
  86. * increase the "Maximum job timeout" to something like ``2h``
  87. * give it a better Description