Systemd Container and Podman in GitHub CI

As D-Installer consists of several components like D-Bus backend, CLI or web frontend, we see a need to test in CI that each component can start and communicate properly with each other. For this we use a test framework and more importantly GitHub CI where we need a systemd container which is not documented at all. In the following paragraphs we would like to share with you how we did it so that so that each of you can be inspired by it or use it for your own project.

A Container Including Systemd

We created a testing container in our build service that includes what is needed for the backend and the frontend. After some iterations, we discovered that we depend on NetworkManager which is really coupled with systemd. Additionally, we needed to access the journal for debugging purposes, which also does not work without systemd. For those reasons, we decided to include systemd.

If you are interested, you can find the container in YaST:Head:Containers/d-installer-testing although you should know that it has some restrictions (e.g., the first process must be systemd init).

GitHub CI

Asking Google, we found no relevant information about running a systemd container on GitHub CI. However, we read a piece of advice about using Podman for such containers due to its advanced support for systemd (which is enabled by default). But for using Podman, most of the answers suggested using a self-hosting workers, something we do not want to maintain.

Just running the systemd container on GitHub CI does not work because GitHub sets the entry point to tail -f (i.e., systemd init is not the first process). However, we noticed that the Ubuntu VM host in GitHub comes with Podman pre-installed. So the solution became obvious.

GitHub CI, Podman and a Systemd Container

The idea is to run Podman as steps in GitHub CI using our systemd container. We did not define container keyword at all but just run it manually. Each step is encapsulated in a podman container exec.

A configuration example looks like this:

  integration-tests:
    runs-on: ubuntu-latest

    steps:

    - name: Git Checkout
      uses: actions/checkout@v3

    - name: start container
      run: podman run --privileged --detach --name dinstaller --ipc=host -v .:/checkout registry.opensuse.org/yast/head/containers/containers_tumbleweed/opensuse/dinstaller-testing:latest

    - name: show journal
      run:  podman exec dinstaller journalctl -b

This snippet checks out the repository, starts the container and prints the journal’s contents. The important part is to set the name of the container so you can use it in the exec calls. Moreover, it mounts the Git check out on the container so it is accessible from there.

Of course, how to use the container to do the real testing is up to you, but at least you have a working systemd container and you can inspect the logs. You can see the full configuration in action in the pull request https://github.com/yast/d-installer/pull/425.

Remaining Issues

For the integration testing of D-Installer we still face some issues:

Different kernel: the Ubuntu VM has a different kernel and we found out that the device mapper kernel module is missing.
Restricted privileges: Not all actions are possible, even on a privileged container. For instance, we cannot mount the host /var/log to container’s /var/log, which was pretty convenient to get log artifacts.
Cannot test the whole installation: We cannot “overwrite” the host VM, so it is not possible to perform a full end-to-end testing of the whole installation process. Not to mention that it might take quite some time (and for each pull request). But that’s fine: our openQA instance will take care of running those tests, although we are still discussing the best way to achieve that.