Re: [libvirt PATCH 5/7] docs: testing: Adjust the docs on how to run container workloads locally

The fact that we need ci/helper script to run the workloads remains true, but the invocation has changed as of commit eb41e456 . We also

extracted GitLab job specs into a standalone ci/jobs.sh script which allows execution of any container job we run in upstream CI locally, unlike the original functionality which only allowed builds, tests and shell (although important to say it could be adjusted with the right meson/ninja args). lcitool also became mandatory as it enables the container execution which replaced a Makefile we used to have for this purpose. Signed-off-by: Erik Skultety <eskultet(a)redhat.com&gt; --- docs/testing.rst | 37 +++++++++++++++++++++++++++++-------- 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/docs/testing.rst b/docs/testing.rst index a597c3ed07..9ca47072ba 100644 --- a/docs/testing.rst +++ b/docs/testing.rst @@ -48,11 +48,17 @@ Running container builds with GitLab CI As long as your GitLab account has CI minutes available, pipelines will run automatically on every branch push to your fork. -Running container builds locally -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Running container jobs locally +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -In order to run container builds locally, we have a ``helper`` script inside -the ``ci`` directory that can pull, build, and test (if applicable) changes on +GitLab CI configuration file is the only source of truth when it comes to +various job specifications we execute as part of the upstream pipeline. +Luckily, all "script" (i.e. Bash scripts) were extracted to standalone Shell +functions in ``ci/jobs.sh``. This allows users to run any of the container +GitLab job specifications locally by just referencing the job name. + +When it comes to actually running the GitLab jobs locally, we have a +``ci/helper`` script can pull, build, and test (if applicable) changes on