DTS unit testing part 1 - Environment

[miczyg1]

The problem you're addressing (if any)

Currently unit tests are ran on host, which is very ugly. We need some environment that has all dependencies available.

To avoid introducing breaking changes, we should test all available boards like that and all possible paths. DTS script logic becomes overcomplex.

Describe the solution you'd like

Having all utilities that DTS has on the host is troublesome. We need an environment where the unit tests can be run easily.

Where is the value to a user, and who might that user be?

No response

Describe alternatives you've considered

No response

Additional context

https://github.com/Dasharo/meta-dts/pull/95#issuecomment-1916610395

[macpijan]

I am in favor of using DTS image in QEMU for the environment. We could "reimplement" DTS environment in Dockerfile for instance, but that would mean additional work, maintaining two environments. Making sure these two are the same would be problematic.

Another approach could be producing container from Yocto build, that could also be feasible.

[macpijan]

I can see I made some attempt of putting the environemnt into nix here: https://github.com/Dasharo/dts/tree/wip

[pietrushnic]

@macpijan strategic thinking should be as follows when we choose the technology stack: Unikernel in VM > App in VM > App in Docker container > App on bare metal OS. Another strategic position of 3mdeb and Dasharo should be to provide open-source firmware for confidential computing, which means the expansion of Dasharo(UEFI) on QEMU Q35 as well as Dasharo(coreboot+UEFI/Heads) on the same target. To sum up, investment in DTS in QEMU is the preferred solution. The fundamental goal should be CI/CD, which runs tests automatically on every PR or every commit and then merges the gate.