SELinux policy forbids systemd-machined from creating a varlink socket,
which it does since v256. This makes it fail to start. Subsequently,
mock fails to build the RPM, because it uses systemd-nspawn as an
isolation and it fails to register the machine with systemd-machined.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Manifest tests on Fedora 39 sometimes fail, because checking out the
specific manifest-db commit fails with:
"error: The following untracked working tree files would be
overwritten by checkout"
Use --force when checking out the ref, which will hopefully solve any
error like this.
[1] https://gitlab.com/redhat/services/products/image-builder/ci/osbuild/-/jobs/7317097983
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Don't instruct mock to not bootstrap the chroot. This is making builds
to fail on F40 due to DNF5. The error message suggests to bootstrap
chroot.
Example:
https://gitlab.com/redhat/services/products/image-builder/ci/osbuild/-/jobs/7239614060#L1363
Note that e.g. osbuild-composer does not specify the
--no-bootstrap-chroot option either.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
We have been observing a race condition in our CI when installing
packages at the beginning of the SUT setup. This happens only on RHEL
and it is caused by the `rhc` tool, which executes some Ansible
playbooks on system startup, which install packages using dnf. This
interferes with dnf commands ran by the `mockbuild.sh` script, which
results in a job failure.
Since there seems to be no way to determine if `rhc` finished "its
thing", let's retry dnf install of packages up to 5 times with
exponential backoff in between retries.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
DNF has more elaborate locking system and can wait for other instances of
itself when installing packages. Using rpm directly to install local
package is causing failures in CI due to it not being able to acquire
lock on `/var/lib/rpm/.rpm.lock`.
Using DNF should improve the situation, although there is no good
documentation to link and support this claim for sure.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
This is how it is done also in osbuild-composer. The downside of doing
this in `deploy.sh` is that team SSH keys are not set as authorized for
mock-build jobs, which make it impossible to log into the machine and
debug anything.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
osbuild CI tests, specifically image tests are not executing the test
script from osbuild-composer any more, but it uses manifest-db.
Therefore it is not needed to set up repository for osbuild-composer nor
install it.
Delete all unneeded lines from the script and replace them by installing
all osbuild packages needed to build images from `manifest-db`.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The default cache location for `osbuild-image-test` is actually
`/var/lib/osbuild/store`. Pass that to `osbuild` when setting
the `maximum cache size to set the size for the correct location.
Integrate the recently added file system cache `FsCache` into our
object store `ObjectStore`. NB: This changes the semantics of it:
previously a call to `ObjectStore.commit` resulted in the object
being in the cache (i/o errors aside). But `FsCache.store`, which
is now the backing store for objects, will only commit objects if
there is enough space left. Thus we cannot rely that objects are
present for reading after a call to `FsCache.store`. To cope with
this we now always copy the object into the cache, even for cases
where we previously moved it: for the case where commit is called
with `object_id` matching `Object.id`, which is the case for when
`commit` is called for last stage in the pipeline. We could keep
this optimization but then we would have to special case it and
not call `commit` for these cases but only after we exported all
objects; or in other words, after we are sure we will never read
from any committed object again. The extra complexity seems not
worth it for the little gain of the optimization.
Convert all the tests for the new semantic and also remove a lot
of them that make no sense under this new paradigm.
Add a new command line option `--cache-max-size` which will set
the maximum size of the cache, if specified.
