This prepares encryption secrets and authentication secrets. When we add
nbdkit-backed network storage sources, we will not need to send
authentication secrets to qemu, since they will be sent to nbdkit
instead. So split this into two different functions.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Jonathon Jongsma [Thu, 19 Jan 2023 19:16:01 +0000 (13:16 -0600)]
qemu: move qemuProcessReadLog() to qemuLogContext
This code can be used by the nbdkit implementation for reading back
filtered log data for error reporting. Move it to qemuLogContext so that
it can be shared. Renamed to qemuLogContextReadFiltered().
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Rather than hard-coding the nbdkit module directory, query the nbdkit
binary for the location to these directories. nbdkit provides a
--dump-config optiont that outputs this information and can be easily
parsed. We can also get the version from this output rather than
executing `nbdkit --version` separately.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
An object for storing information about a nbdkit process that is serving
a specific virStorageSource. At the moment, this information is just
stored in the private data of virStorageSource and not used at all.
Future commits will use this data to actually start a nbdkit process.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add the virFileCache implementation for nbdkit capabilities to the qemu
driver. This allows us to determine whether nbdkit is installed and
which plugins are supported. it also has persistent caching and the
capabilities are re-queried whenever something changes.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
qemu: implement persistent file cache for nbdkit caps
Implement the loadFile and saveFile virFileCacheHandlers callbacks so
that nbdkit capabilities are cached perstistently across daemon
restarts. The format and implementation is modeled on the qemu
capabilities, but simplified slightly.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Since the libvirt documentation suggests to prefer GObject over
virObject, and since virObject is a GObject, change virFileCache to
allow GObjects as data.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In order to add caching of the nbdkit capabilities, we will need to
compare against file modification times, etc. So look up this
information when creating the nbdkit caps.
Add a nbdkit_moddir build option to allow the builder to specify the
location to look for nbdkit plugins and filters.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
qemu: Add functions for determining nbdkit availability
In future commits, we will optionally use nbdkit to serve some remote
disk sources. This patch queries to see whether nbdkit is installed on
the host and queries it for capabilities. The data will be used in later
commits.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Jim Fehlig [Mon, 18 Sep 2023 15:59:39 +0000 (09:59 -0600)]
libxl: Fix Domain-0 ballooning logic
When Domain-0 autoballooning is enabled, it's possible that memory may
need to be ballooned down in Domain-0 to accommodate the needs of another
virtual machine. libxlDomainFreeMemory handles this task, but due to a
logic bug is underflowing the variable containing Domain-0 new
target memory. The resulting huge numbers are filtered by
libxlSetMemoryTargetWrapper and memory is not changed.
Under the covers, libxlDomainFreeMemory uses Xen's libxl_set_memory_target
API, which includes a 'relative' parameter for specifying how to set the
target. If true, the target is an increment/decrement value over the
current memory, otherwise target is taken as an absolute value.
libxlDomainFreeMemory sets 'relative' to true, but never allows for
negative values by declaring the target memory variable as an unsigned.
Fix by declaring the variable as signed, which also requried adjusting
libxlSetMemoryTargetWrapper.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Erik Skultety [Wed, 13 Sep 2023 09:49:09 +0000 (11:49 +0200)]
ci: jobs.sh: Define and create SCRATCH_DIR for local executions
Running outside of GitLab will likely not have the variable set and
hence the execution would fail. To make sure we always start with a
clean scratch dir (which may or may not be the best thing), create it
with 'mktemp'. The main reason for a temporary directory is to ensure a
clean environment for the job every time run_integration function is
run. For repeated interactive use case, it is imperative that the
developer takes care of their environment.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Wed, 13 Sep 2023 09:21:08 +0000 (11:21 +0200)]
ci: jobs.sh: run_integration: Print DAEMONS variable for debugging
One advantage that GitLab's YAML has with Shell commands is that every
single line is printed out as is, including control structures. In
order to see whether the logic did the same thing and the tests are
going to operate on the right set of daemons (monolithic vs modular),
lets print the DAEMONS variable that we set depending on the distro we
execute the tests on.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Tue, 12 Sep 2023 14:30:19 +0000 (16:30 +0200)]
ci: jobs.sh: integration: Execute commands via 'run_cmd[_quiet]' helpers
Unfortunately, once we go down the line of running our own scripts as
part of GitLab CI jobs rather than open coding Shell in YAML, we lose
the benefit of seeing each line the script executes. The downside of
the default YAML however is that we have to maintain the same piece of
code on 2 places in that case. Let's adopt what we use with other
container jobs and prefix each shell command with 'run_cmd' or
'run_cmd_quiet' which will dump it in the logs before executing.
Flow control expressions and structures are a problem though in this
regard, so let's just print some important values for debugging
purposes.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Tue, 19 Sep 2023 08:46:08 +0000 (10:46 +0200)]
ci: jobs.sh: Introduce a quiet version of run_cmd
We've started using the run_cmd helper function to log what kind of
command is being executed as well as actually executing the command.
The problem however is doing I/O redirections for commands which we
don't wish to see any output for whatever reason. Now, if the
redirection is applied at parameter passing to run_cmd it's going to be
applied to the debug print as well. Let's introduce another helper,
run_cmd_quiet which takes care of the I/O redirection and executes the
command completely silently.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Because of the nature of writing inline shell commands to YAML, most of
the commentaries where inlined with the command not to hinder YAML
readability any further. Since we moved the logic to a standalone
script, we can now do whatever formatting & readability adjustments we
want.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Fri, 15 Sep 2023 12:46:39 +0000 (14:46 +0200)]
ci: jobs.sh: integration: Use --quiet with virsh
We've not been interested in any extra output from the command at all
since we always redirected both stdout and stderr to /dev/null. Future
patch will change that slightly, so --quiet will start making sense.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Fri, 15 Sep 2023 12:41:57 +0000 (14:41 +0200)]
ci: jobs.sh: Drop comment about the need for Avocado 98.0
We needed v98.0 in commit c9a65eb8 due to a bug in Avocado in the past
and have been installing the latest Avocado for a while since commit 91774931, yet we kept the comment by a mistake.
Besides, looks like v98.0 ignores the avocado.config file in the TCK
repo instructing it to run the test suite sequentially leading to test
stability issues, so abandoning the v98.0 in commit 91774931 was a good
thing in the end.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Wed, 13 Sep 2023 15:05:02 +0000 (17:05 +0200)]
ci: integration: Adjust the check for CentOS Stream version
All supported versions of Fedora and CentOS Stream 9 default to modular
setup, it's probably better if we cosmetically adjust the CentOS Stream
version check to make it explicit that monolithic daemon services ought
to be started only on Stream 8.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Fri, 27 Jan 2023 07:52:17 +0000 (08:52 +0100)]
syntax-check: Drop the shell's 'check for minus' rule
Apparently we've only had it because the -[ao] options weren't portable
at the time, but according to
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
both are defined in POSIX.1-2017 revision which is old enough for all
our supported platforms to have adopted it already, so we can drop the
check. However, the above has also marked -[ao] as obsolescent stating
that:
"[OB] Obsolescent
The functionality described may be removed in a future version of
this volume of POSIX.1-2017. Strictly Conforming POSIX Applications
and Strictly Conforming XSI Applications shall not use obsolescent
features."
It is however unlikely that the shell implementations would drop
support for -[ao] despite POSIX potentially removing them.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Michal Privoznik [Mon, 18 Sep 2023 09:28:31 +0000 (11:28 +0200)]
src: Avoid needless checks before calling g_strdup()
There are few places where the following pattern occurs:
if (var)
other = g_strdup(var);
where @other wasn't initialized before g_strdup(). Checking for
var != NULL is useless in this case, as that's exactly what
g_strdup() does (in which case it returns NULL).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: K Shiva Kiran <shiva_kr@riseup.net> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
conf: Add methods to create Metadata change events
Adds two new private methods to create metadata change events:
- virNetworkEventMetadataChangeNewFromNet()
- virNetworkEventMetadataChangeNewFromObj()
Signed-off-by: K Shiva Kiran <shiva_kr@riseup.net> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When changing the metadata via virNetworkSetMetadata(), we can
now emit an event to notify the app of changes. This is useful
when co-ordinating different applications read/write of custom
metadata.
Signed-off-by: K Shiva Kiran <shiva_kr@riseup.net> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Thu, 14 Sep 2023 13:53:12 +0000 (15:53 +0200)]
virDomainDiskSourceNVMeParse: Use virXMLPropULongLong()
Inside of virDomainDiskSourceNVMeParse() we have
virXMLPropString() + virStrToLong_ull() combo. Switch to
virXMLPropULongLong() which does the same thing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 13 Sep 2023 15:30:45 +0000 (17:30 +0200)]
src: Drop needless typecast to virDomainDiskBus
The 'bus' member of _virDomainDiskDef is already declared of
virDomainDiskModel type. Hence, there is no need to typecast the
variable when passing to switch() statements.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu_domain_address: Drop needless typecast to virDomainDiskModel
The 'mode' member of _virDomainDiskDef is already declared of
virDomainDiskModel type. Hence, there is no need to typecast the
variable when passing to switch() statements.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 13 Sep 2023 15:11:12 +0000 (17:11 +0200)]
src: Drop needless typecast to virDomainDeviceType
The 'type' member of _virDomainDeviceDef is already declared of
virDomainDeviceType type. Hence, there is no need to typecast the
variable when passing to switch() statements.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu: Drop needless typecast to virDomainFSDriverType
The 'fsdriver' member of _virDomainFSDef is already declared of
virDomainFSDriverType type. Hence, there is no need to typecast
the variable when passing to switch() statements.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu_domain_address: Drop needless typecast in qemuDomainDeviceCalculatePCIConnectFlags()
Inside of qemuDomainDeviceCalculatePCIConnectFlags() there's a
switch() which typecasts a variable of
virDomainHostdevSubsysSCSIVHostModelType type to the very same
type. This is useless.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are few places where a virDomainHostdevDef->source.subsys
is accessed without ->mode being checked. Mind you,
virDomainHostdevDef can be also in
VIR_DOMAIN_HOSTDEV_MODE_CAPABILITIES mode.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 13 Sep 2023 12:41:00 +0000 (14:41 +0200)]
lxc_controller: Access correct union member in virLXCControllerSetupHostdevCaps()
The point of virLXCControllerSetupHostdevCaps() is to access
.caps union member of given <hostdev/> source. And it does so in
the switch, but then, when reporting an error the .subsys member
is accessed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Boris Fiuczynski [Thu, 14 Sep 2023 13:15:55 +0000 (15:15 +0200)]
qemuxml2argvtest: Fix tests failing on none x86 host CPUs
Since commit 54257ed51b51 on S390x qemuxml2argvtest fails with the following errors:
144) QEMU XML-2-ARGV cpu-kvmclock.x86_64-latest ... libvirt: CPU Driver error : the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor
FAILED
2023-09-14 13:01:23.883+0000: 4113077: info : libvirt version: 9.8.0
2023-09-14 13:01:23.883+0000: 4113077: info : hostname: a46lp61.lnxne.boe
2023-09-14 13:01:23.883+0000: 4113077: error : virCPUx86Compare:1954 : the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor
1059) QEMU XML-2-ARGV cpu-check-partial.x86_64-latest ... libvirt: CPU Driver error : the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor
FAILED
2023-09-14 13:01:23.885+0000: 4113077: error : virCPUx86Compare:1954 : the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor
1064) QEMU XML-2-ARGV cpu-check-default-partial2.x86_64-latest ... libvirt: CPU Driver error : the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor
FAILED
2023-09-14 13:01:23.885+0000: 4113077: error : virCPUx86Compare:1954 : the CPU is incompatible with host CPU: Host CPU does not provide required features: monitor
3 tests failed.
Fixes: 54257ed51b5132032cedb7e1e7b8c34b9ae52115 Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Erik Skultety [Wed, 13 Sep 2023 10:51:01 +0000 (12:51 +0200)]
ci: jobs.sh: Add back '--no-suite syntax-check --print-errorlogs'
Commit f688a53a converted .gitlab-ci.yml to the usage of ci/jobs.sh
functions, but in doing that our test options
'--no-suite syntax-check --print-errorlogs'
got lost in the process and since commit 8e660c52 didn't introduce them
in the first place, it caused a behavioral regression. This patch adds
them back.
Fixes: 8e660c5286d7e2d07dd61681074bf1555955552d Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Jonathon Jongsma [Tue, 30 May 2023 20:53:38 +0000 (15:53 -0500)]
qemu: consider vdpa block devices for memlock limits
vDPA block devices will also need the same consideration for memlock
limits as other vdpa devices, so consider these devices when calculating
memlock limits.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Jonathon Jongsma [Tue, 30 May 2023 20:33:46 +0000 (15:33 -0500)]
qemu: make vdpa connect function more generic
qemuInterfaceVDPAConnect() was a helper function for connecting to the
vdpa device file. But in order to support other vdpa devices besides
network interfaces (e.g. vdpa block devices) make this function a bit
more generic.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Jonathon Jongsma [Fri, 17 Mar 2023 15:25:47 +0000 (10:25 -0500)]
qemu: add virtio-blk-vhost-vdpa capability
Check whether the qemu binary supports the vdpa block driver. We can't
rely simply on the existence of the virtio-blk-vhost-vdpa block driver
since the first releases of qemu didn't support fd-passing for this
driver. So we have to check for the 'fdset' feature on the driver
object. This feature will be present in the qemu 8.1.0 release and was
merged to qemu in commit 98b126f5.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 11:30:46 +0000 (13:30 +0200)]
ci: helper: Drop the _make_run method
We've successfully migrated over to lcitool to take care of the
container workload execution, so dropping this 'make' prep code is a
prerequisite of finally getting rid of the ci/Makefile script.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Fri, 25 Aug 2023 16:03:48 +0000 (18:03 +0200)]
ci: helper: Drop the --meson-args/--ninja-args CLI options
These originally allowed customizing the ci/Makefile script which was
the core of the local container executions. The problem was that
however flexible this may have been, it never mirrored what was being
done as part of the GitLab jobs. Motivated by the effort of mirroring
GitLab jobs locally, these would only ever make sense to be set/used in
interactive shell container sessions where the developer is perfectly
capable of using the right meson/ninja CLI options directly without
going through another shell variable indirection as it was the case
with these ci/helper options.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 11:29:56 +0000 (13:29 +0200)]
ci: helper: Drop original actions
Previous patches added a single 'run' command parametrized with GitLab
job specs via '--job' that cover all of these original actions, adding
some more in the process. Drop the original actions as we don't need
them anymore.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 09:07:09 +0000 (11:07 +0200)]
ci: helper: Add a job argparse subparser
The idea behind this subcommand is to follow whatever build job we have
defined in the GitLab CI pipeline, so that we only have a single source
of truth for the recipes. Adds 'shell' as an extra option for
interactive container build debugging.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 11:21:12 +0000 (13:21 +0200)]
ci: helper: Rework _lcitool_run method logic
This method wasn't even utilized before this patch. This patch adds all
the necessary logic to successfully execute a container workload via
lcitool (which will later allow us to ditch ci/Makefile). Because
container executions via lcitool creates the following inside the
container:
$ ls
script datadir
where 'datadir' is the workload directory (in this case a local git
repo clone) and 'script' is the code that runs whatever the workload is
over 'datadir'.
In order to satisfy the ^above, our helper generates a trivial
temporary 'script' that will source ci/build.sh and run whatever was
specified as --job essentially to simulate the exact steps a GitLab
pipeline job would go through.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 08:24:12 +0000 (10:24 +0200)]
ci: helper: Add Python code hangling git clones
This helper will be utilized by a future patch which will add the
lcitool container execution logic. The reason why the required_deps
decorator isn't being used here is because this is a property.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 08:28:55 +0000 (10:28 +0200)]
ci: helper: Add a required_deps higher order helper/decorator
Since we'll depend on GitPython for repo cloning, we need to make sure
to emit a user friendly error if the module is not installed. This
patch introduces a helper which future patches will use as a decorator.
Inspiration for this helper has been taken out of lcitool where we use
an identical helper for this purpose.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 08:32:24 +0000 (10:32 +0200)]
ci: helper: Don't make ':' literal a static part of the image tag
':' is just a connecting character, we can add it to the appropriate
place later in the Python script later, but it doesn't make sense to be
part of the image 'tag' string.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 14:05:41 +0000 (16:05 +0200)]
.gitlab-ci.yml: Convert the potfile job to the build.sh usage
Individual shell command executions are replaced by respective
functions in the ci/build.sh base script. This will make sure we use
the same recipes in GitLab jobs as well as in local executions.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 14:05:41 +0000 (16:05 +0200)]
.gitlab-ci.yml: Convert the codestyle job to the build.sh usage
Individual shell command executions are replaced by respective
functions in the ci/build.sh base script. This will make sure we use
the same recipes in GitLab jobs as well as in local executions.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 14:05:41 +0000 (16:05 +0200)]
.gitlab-ci.yml: Convert the website build job to the build.sh usage
Individual shell command executions are replaced by respective
functions in the ci/build.sh base script. This will make sure we use
the same recipes in GitLab jobs as well as in local executions.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 14:05:41 +0000 (16:05 +0200)]
.gitlab-ci.yml: Convert the cross build job to the build.sh usage
Individual shell command executions are replaced by respective
functions in the ci/build.sh base script. This will make sure we use
the same recipes in GitLab jobs as well as in local executions.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 14:05:16 +0000 (16:05 +0200)]
.gitlab-ci.yml: Convert the native build job to the build.sh usage
Individual shell command executions are replaced by respective
functions in the ci/build.sh base script. This will make sure we use
the same recipes in GitLab jobs as well as in local executions.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Wed, 1 Feb 2023 10:11:32 +0000 (11:11 +0100)]
.gitlab-ci.yml: Add 'after_script' stage to prep for artifact collection
This is one of the preparation steps that if not done would otherwise
collide with local container executions where we:
1) don't collect artifacts
2) are not limited by GitLab's environment and hence moving build
artifacts to unusual places would only cause confusion when doing
local build inspection in an interactive container shell session
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Mon, 11 Sep 2023 13:28:52 +0000 (15:28 +0200)]
ci: Rename build.sh -> jobs.sh
After the recent changes, this script no longer executes any logic
anymore, it merely defines the jobs run in the GitLab environment. In
order to use it, one has to source the file in the environment and then
run one of the job "functions". For that, the 'build.sh' name is no
longer descriptive enough and 'jobs.sh' feels more suitable and less
misleading.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 13:49:19 +0000 (15:49 +0200)]
ci: build.sh: Drop direct invocation of meson/ninja commands
We've moved all invocations to the respective helper function which
we'll execute both from gitlab CI jobs and local environments so we
don't need to have them on the global level as it would also not work
with "sourcing" this file to populate the environment with function
definitions.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 13:41:38 +0000 (15:41 +0200)]
ci: build.sh: Drop changing working directory to CI_CONT_DIR
Firstly, this would mangle with "sourcing" this file in either
execution environment later down the road. Secondly, we won't need this
as future ci/helper patches will generate a throwaway script that will
take care of a correct execution of a build job in a similar fashion as
if the job ran in a GitLab environment.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 13:48:46 +0000 (15:48 +0200)]
ci: build.sh: Add a wrapper function over the 'potfile' job
This helper is a shell function transcript of its original GitLab CI
counterpart. There's one notable difference such that we pass '-j1' to
the meson compile command otherwise we'd have to execute the 'run_build'
function twice, passing 'libvirt-pot-dep' and 'libvirt-pot' targets
in a serial manner.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 13:47:48 +0000 (15:47 +0200)]
ci: build.sh: Add a helper function to create the dist tarball
This helper function does not correspond to a particular GitLab job, it
just logically separates the necessary step of creating a dist tarball
from the RPM build job that takes over.
One notable change here is the need to update git's file index which
causes issues in local container executions which rely on a shallow
copy of the libvirt repo created as:
$ git clone --local
Even if all changes have been committed, git often complained
otherwise. Updating the index in a GitLab environment is a NOP.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 13:44:52 +0000 (15:44 +0200)]
ci: build.sh: Add a wrapper function over meson's setup
The reason for this wrapper is that all job functions introduced in
future patches will refer to this one instead of open-coding the same
'meson setup' invocation N times. It also prevents 'setup' to be called
multiple times as some future job functions might actually do just that
in a transitive manner.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Erik Skultety [Thu, 24 Aug 2023 13:45:44 +0000 (15:45 +0200)]
ci: build.sh: Add a wrapper function executing 'shell' commands
This would normally be not needed at all, but the problem here is the
Shell-in-YAML which GitLab interprets. It outputs every command that
appears as a line in the 'script' segment in a color-coded fashion for
easy identification of problems. Well, that useful feature is lost when
there's indirection and one script calls into another in which case it
would only output the respective script name which would make failure
investigation harder. This simple helper tackles that by echoing the
command to be run by any script/function with a color escape sequence
so that we don't lose track of the *actual* shell commands being run as
part of the GitLab job pipelines. An example of what the output then
might look like:
[RUN COMMAND]: 'meson compile -C build install-web'
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>