Proposal: Utilizing Container Registry for Shared BitBake Sstate-Cache

Yash Patel <[email protected]> Thu, 4 Jun 2026 09:15:42 -0500
Newsgroups org.ozlabs.lists.openbmc
Message-ID <CAGwee5_2x89EVnnkXpV3_NXNAPqqjOx1sknC7aegU5Zui+bjVA@mail.gmail.com>
Hello Team,

My name is Yash Patel and I'm a summer intern at IBM working with
Andrew Geissler. My goal is to start storing the sstate for our
bitbake builds into containers and upload them to a container registry
that the openbmc CI process can utilize as well as other openbmc
developers. This will make it much easier to bring new build nodes
online and to reset bad ones. It will also allow openbmc developers to
be able to quickly spin up a container and do bitbakes quickly for a
target machine with the sstate already pre-loaded.

There would be a container per machine type. The default machines
supported would be what we run CI for up at
https://jenkins.openbmc.org/job/ci-openbmc/. Supporting only a single
machine per container will keep the size of the container down and
most use cases are just building a single machine. Also, a lot of the
free opensource container registries have size limits on the
containers.

We are thinking that the
https://jenkins.openbmc.org/job/latest-master/ job will be what
generates and uploads the containers. Currently this job runs once a
day and builds whatever is in master at the time (we could tweak this
schedule if needed). We would then update
https://github.com/openbmc/openbmc-build-scripts/blob/master/build-setup.sh
(script used by openbmc CI) to look for an available container and use
it if available, otherwise just default to the standard flow.

We would generate containers for both x86 and arm as they will have
different sstates.

We've done some research and it appears that github provides a free
container registry for open source projects so this is the direction
we're thinking.

Any thoughts or comments appreciated!
Yash