I am currently working on integration tests involving Bluetooth Low Energy (BLE) devices, and I want to perform these tests within Docker containers. The firmware of these BLE devices is portable enough that I can test it in posix (i.e. Zephyr RTOS). In posix the bluetooth controller stack of Zephyr can connect to a remote host with TCP (i.e. hci protocol over TCP) which allows me to do integration tests with my linux application (i.e. BLE gateway).
Instead of connecting to a real HCI interface from Bluez I create a TCP server that functions as a Bluetooth controller over TCP. This is done with the experimental software from Google called Bumble.
Another neat feature of bumble is that it can create a bridge to other protocols (e.g. virtual hci interface for Bluez, virtual hci serial interface and even the new inteface from Android called android-netsim).
Based on this context I am now able to develop integration tests without hardware on both sides!. I.e. My Linux BLE gateway can connect to a virtual hci interface which connects to my posix variant of the BLE Iot Firmware for the MCU.
This works nice on my host linux PC. But I want to automate this in CI/CD (github actions and gitlab). However, when using Bluez within Docker, it requires access to the Bluetooth host on the host PC. This kind of breaks the purpose of having virtual bluetooth communication when I need a physical host with bluetooth access.
I have found a workaround by configuring a CI/CD runner with Bluetooth host access, but I would prefer to run everything virtually using default runners (spawned by the CI/CD platform) to avoid relying on a dedicated server (whats the purpose of running virtual bluetooth tests when I need a dedicated server that exposes dbus and bluez to the docker container? )
Is there a way or a hack to make Bluez in Docker work without giving it access to /var/run/dbus/ ?
My motivation is that I want to do integration tests between my Embedded device that supports posix with my BLE gateway (linux + Bluez).