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