Update parent image to bookworm.
This allows us to remove all the backports and also to build Ubuntu
images again as it requires dpkg zstd support.
Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Nothing special here - a simple test.yaml akin to the existing ones.
The pacman.conf file is effectively vanilla config that comes with the
pacman package, while the mirrorlist file is a list of UK https mirrors
that I've been using for years.
Note that there is no canonical mirror for Arch. The top-level/tier 1
Arch server should _not_ be used as per the official recommendation.
Instead we use the mirrors set in the official arch docker tooling.
v2:
- Also install archlinux-keyring and makepkg
- Use arch + backend=qemu only testing matrix
v3:
- Use the same mirrors as the Arch docker images tooling
- Build and install pacman locally, until we get an official package
v4:
- Remove the local pacman build - it's available in backports
v5:
- Explicitly pull arch-install-scripts from backports, normal one lack
pacstrap
v6:
- Manually pull the latest keyring - Debian one is outdated
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The docker-compose test strategy was mainly done for integration with
dockerhub, but as dockerhub no longer builds our images it's not that
relevant.
What's more interesting is to use the docker container we've build to
run a selection of debos recipes, whose successfull build indicate
success. This both makes it easier to test locally as well (just run the
debos recipe) and makes the test jobs more specific.
On top of the existing test this also adds a "debian" test which does some basic
debian smoketesting (debootstrap and apt) as well as a basic
"partitioning" test. The partitioning test unforutunately doesn't work
in the nofakemachine run as udev isn't available in the container, so
that only runs on UML and Qemu based backends.
Current the kvm backend isn't tested because the standard github action
runners don't support kvm. But qemu, though being lots slower, covers
some part of it.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
This is a continuation of work done by @eds-collabora in !275
This replaces the old, simpler pipeline with a three phase process:
- First, build the image and cache it using docker buildx.
- Second, run all the tests in parallel, restoring the image from the cache.
- Thirdly, if the tests pass:
- if this is a push to the main branch, push to DockerHub.
- push to GitHub Container registry (PS: will push to a user's own fork).
This uses Buildkit caching aggressively, and will make use of the entire 5GiB allocation of cache space that GitHub provides over time.
It requires the following additional repository secrets:
- DOCKERHUB_USERNAME: the username to login as on DockerHub (e.g. go-debos)
- DOCKERHUB_PASSWORD: an access token for the DockerHub repository.
Closes: #275
Based on original work by: Ed Smith <ed.smith@collabora.com>
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Since we are now building using go modules, let's remove
the hacks for various dependencies and build the docker
container using the go modules.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Running the tests on the host is a good first step; to test Debos
properly we should run inside a Fakemachine. Since GitHub actions
do not support creating nested virtual machines, use the
user-mode-linux backend in Fakemachine to create a user process
to run the tests inside of.
Since Docker autobuild does not support UML the docker-compose
file purposely does not have a suffix of `.test.yml` so that the
test will not be picked up to run on Docker autobuild.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Currently we assume all of the tests are run without fakemachine;
since we are looking to run the tests with fakemachine as well,
let's allow arguments to be passed to the test script which are
then passed to debos.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Currently only the unit-tests under the actions directory are ran. This
patch runs all of the available unit tests in the project.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
This patch adds support for XFS, including the ability
to specify the UUID through the fsuuid property of the
image-partition action.
Signed-off-by: Nguyen Thi Huong <huong4.nguyenthi@toshiba.co.jp>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
Debian's qemu-user-static package no longer registers binfmts on postinst
when running inside a virtualmachine; dockerhub builds are now built inside
a vm so the binfmts are not generated inside the docker container.
Fixes: 91af617bea ("docker: Install qemu-user-static 6.0 to fix segfault")
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
There are issues with qemu-user-static 5.2 crashing when attempting
to allocate guest memory when compiled as a proper statically-linked
binary.
From testing, qemu 6.0 fixes the bug but it's not yet clear which
patch fixes the bug. So until the correct patch is backported to
bullseye, let's install qemu from experimental to pickup the bugfix.
See: #245
See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988174
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Since we have the support for the new user-mode-linux backend in the
docker container, Debos defaults to attempting to use that.
Unfortunately that isn't possible to run inside the Docker Hub where the
test suite runs, so let's explicitly disable the fakemachine library
when running the Docker Hub test suite.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
The fakemachine uml backend uses user-mode-linux and libslirp-helper
packages available from bullseye, let's include those inside the container.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
The equivs package is used to create dummy Debian packages which can
be useful in development to satisfy dependencies without installing the
real package. Note that this package is not the recommended way of
dealing with broken dependencies: a bug report should be filed instead.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Testify is currently not built unless the manual tests are ran at which
point testify compiliation fails due to requiring a newer version of
golang than in buster. Unfortunately the main branch is no longer
compatible, so install from source to get the unit tests running again.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Debos currently sets the partition type to filesystem type and
does not allow the partition type to be set from the recipe.
In some situations setting the partition type is required, so add the
property `PartType` to the Partition and set the partition type to the value
of that property. If the `PartType` property is unset, the original partition
type is retained thus not breaking backwards compatibility.
For msdos, the partition type should be hexadecimal and 2-characters long.
For gpt, the partition GUID should be in GUID format and 36-characters long.
Some examples and further reading is included in the documentation.
Resolves: #98
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Add the u-boot-tools package to be able to use binaries such as
mkimage in debos' recipes.
Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com>
Move simple test to simple dir.
Add test with recipe included from sub-directory.
Add test with recipe included from directory outside of main recipe path.
Add script to run tests in sequence.
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
The usage of the container as an executable does not seems to be
straightforward.
Add a warning in docker/README.md and add container installation reference
in main README.md.
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
The ENTRYPOINT set the image’s main command, allowing that image to
be run as though it was that command. With 'docker run', the command
parameters could be passed directly after the container's name.
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
This test run on the final debos-docker container.
It doesn't use actions which act on image files which either needs
fakemachine or access to loop devices.
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
This allows to automatically run debos unit test on dockerhub when
a build is triggered.
The unit test are run on "builder" target image, which needs to make
GOPATH available from the container and add go packages dependency for
the test.
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
Copy the local debos source during container build instead of downloading
master debos branch from github.
This allows to use docker container during debos development.
Add apt-transport-https, pkg-config and btrfs-progs packages to runtime
dependencies.
Remove dbus package which is not requested (see
https://gitlab.collabora.com/docker/debos/blob/master/docker/Dockerfile)
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
Move builder and runner stages to buster-slim to get newer versions
of go, deboostrap and libostree.
Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
The problem with building for non-host arch as described in the:
https://github.com/go-debos/debos/issues/9 was resolved. Basic
arm64 example image building was tested on the Ubuntu 18.04.
This may enable more users to take advantage of the debos, as
using it on non-Debian distros seems either impossible or not
trivial.
