GitLab

Set guest CPU to "host" model

See merge request !10

ShellCheck identified the following issue:

    In ./executor.sh line 164:
    eval "do_${MODE}" "$@"
                       ^-- SC2294 (warning): eval negates the benefit of arrays. Drop eval to preserve whitespace/symbols (or eval as string).

Using eval on an array like $@ removes boundary information we need to
preserve for the do_run function.

Also see https://www.shellcheck.net/wiki/SC2294.

bullseye is the image with the Python QA tools.

Currently, we don't explicitly set the guest CPU model when creating a
virtual machine, and libvirt picks whatever is the platform default. The
libvirt CPU default model is "qemu64/kvm64", which makes Oracle Linux 9
panic on boot, see https://bugzilla.redhat.com/2094260. Setting CPU to
"host" lets libvirt use the closes analog to the host CPU, which works
for Oracle Linux 9.

Add "cleanup_file_variables" stage

See merge request !7

GitLab Runner 13.5.0 added the "cleanup_file_variables" sub stage to the
"run_exec" stage of every GitLab CI job.  Update all Custom executor
scripts so that they handle that sub stage appropriately.

Add an executor for Docker on Windows

See merge request !6

Use CUSTOM_ENV_CI_JOB_IMAGE

See merge request !5

The CUSTOM_ENV_CI_JOB_IMAGE variable contains the value of the "image"
key set for a given GitLab CI job.  Use that instead of the job name for
determining the QCOW2 image to use, so that defining GitLab CI jobs
using the libvirt/QEMU custom executor becomes a bit more similar in
spirit to defining jobs using the Docker executor.

Add step_script stage

See merge request !3

GitLab Runner 13.1.0 seems to add a "step_script" stage. Without this
stage recognized libvirt jobs fail with:

    Executing "step_script" stage of the job script
    Unsupported run stage 'step_script'

The "step_script" stage is not documented upstream.

Add QEMU-based libvirt executor

See merge request !2

Run ShellCheck in GitLab CI

See merge request !1