Automatically test built Docker containers for open-BMC

[AtomicFS]

No description provided.

[MDr164]

Automatically testing those containers on GitHubs runners might not be possible due to them requiring a lot of disk space. I guess we will have to blindly create those and then test those locally. Generally speaking the container to do so is not that complex. Building OpenBMC is a matter of having a sane base e.g. Ubuntu as we use on the other containers, the dependencies as usual (mostly python, gcc toolchain, etc.) and then run two commands: . setup $BOARD_NAME followed by bitbake obmc-phosphor-image. After that grab a coffee in the neighboring city by bike and go back, if you're lucky the process has finished by then.

[AtomicFS]

Might be interesting idea to look into KAS which does not build everything from source, but from pre-compiled distro repositories.

• docs
• Blogpost: Setting Up Yocto Projects with kas

[MDr164]

I recently had a discussion about extending CI storage in ephemeral runners using online network storage which might solve the issue of being limited to 14G storage BUT will in turn slow down file operations even further. The idea would be to mount something like an S3 bucket into the runner and then set the working directory into the mounted network storage, effectively enlarging the disk space to what is needed. But I still don't think this is the best solution here.

[AtomicFS]

While that is an option, I fear it would slow down the build my at least an entire order of magnitude.
Just by comparing cheap SSD read speeds (500 MB/s for 2.5" and 1600 MB/s for M.2 SATA) vs 1 Gb/s connection (128 MB/s). That is assuming that you get full speed out of the network with no overhead. They are probably hosting their runners on faster HW than some cheap SSD.

[AtomicFS]

Sorry, closed by mistake.