Jobs based on custom runners: documentation and configuration placeholder

As described in the included documentation, the "custom runner" jobs
extend the GitLab CI jobs already in place.  One of their primary
goals of catching and preventing regressions on a wider number of host
systems than the ones provided by GitLab's shared runners.

This sets the stage in which other community members can add their own
machine configuration documentation/scripts, and accompanying job
definitions.  As a general rule, those newly added contributed jobs
should run as "non-gating", until their reliability is verified (AKA
"allow_failure: true").

Signed-off-by: Cleber Rosa <crosa@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Message-Id: <20210630012619.115262-2-crosa@redhat.com>
Message-Id: <20210709143005.1554-2-alex.bennee@linaro.org>
This commit is contained in:
Cleber Rosa 2021-07-09 15:29:26 +01:00 committed by Alex Bennée
parent 4aa2454d94
commit b38a04f71f
4 changed files with 48 additions and 0 deletions

View File

@ -0,0 +1,14 @@
# The CI jobs defined here require GitLab runners installed and
# registered on machines that match their operating system names,
# versions and architectures. This is in contrast to the other CI
# jobs that are intended to run on GitLab's "shared" runners.
# Different than the default approach on "shared" runners, based on
# containers, the custom runners have no such *requirement*, as those
# jobs should be capable of running on operating systems with no
# compatible container implementation, or no support from
# gitlab-runner. To avoid problems that gitlab-runner can cause while
# reusing the GIT repository, let's enable the clone strategy, which
# guarantees a fresh repository on each job run.
variables:
GIT_STRATEGY: clone

View File

@ -9,3 +9,4 @@ include:
- local: '/.gitlab-ci.d/crossbuilds.yml' - local: '/.gitlab-ci.d/crossbuilds.yml'
- local: '/.gitlab-ci.d/buildtest.yml' - local: '/.gitlab-ci.d/buildtest.yml'
- local: '/.gitlab-ci.d/static_checks.yml' - local: '/.gitlab-ci.d/static_checks.yml'
- local: '/.gitlab-ci.d/custom-runners.yml'

32
docs/devel/ci.rst Normal file
View File

@ -0,0 +1,32 @@
==
CI
==
QEMU has configurations enabled for a number of different CI services.
The most up to date information about them and their status can be
found at::
https://wiki.qemu.org/Testing/CI
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>`__.

View File

@ -27,6 +27,7 @@ Contents:
migration migration
atomics atomics
stable-process stable-process
ci
qtest qtest
decodetree decodetree
secure-coding-practices secure-coding-practices