On 19/02/2021 22.58, Cleber Rosa wrote:
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 <cr...@redhat.com>
---
.gitlab-ci.d/custom-runners.yml | 14 ++++++++++++++
.gitlab-ci.yml | 1 +
docs/devel/ci.rst | 28 ++++++++++++++++++++++++++++
docs/devel/index.rst | 1 +
4 files changed, 44 insertions(+)
create mode 100644 .gitlab-ci.d/custom-runners.yml
create mode 100644 docs/devel/ci.rst
diff --git a/.gitlab-ci.d/custom-runners.yml b/.gitlab-ci.d/custom-runners.yml
new file mode 100644
index 0000000000..3004da2bda
--- /dev/null
+++ b/.gitlab-ci.d/custom-runners.yml
@@ -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 recursive submodule
+# strategy.
+variables:
+ GIT_SUBMODULE_STRATEGY: recursive
Is it really necessary? I thought our configure script would take care of
the submodules?
Apart from that:
Acked-by: Thomas Huth <th...@redhat.com>
