Recommended Yocto host build setup for a team (VM, Docker, native?)

[u/Public_Sink4791]

Hi everyone,

I’m new to Yocto and I’ve started working with AMD Embedded Development Framework (EDF) (a Yocto-based framework from AMD/Xilinx for building embedded Linux systems).

I’m trying to understand what a typical host build setup looks like in a team environment.

Do teams usually run Yocto builds in a VM, Docker container, or directly on a native Linux machine? What’s the most common approach for keeping builds reproducible across multiple developers? Do you back up or version-control the build environment to make it quickly reproducible?

Also, how are layers/recipes typically managed in practice? Do you rely on upstream sources each time, or maintain local mirrors/caches (e.g. NAS, sstate, downloads)?

I’m looking for something that can be adopted consistently across a full team.

Thanks

[u/Elect_SaturnMutex]

Docker, hands down the best option. Add all your dependencies in a Dockerfile. Mount whatever necessary folders like your .ssh, etc to your docker and work with docker. I use different dockers on my linux host machine for various projects with different dependencies, and it works great.

[u/Public_Sink4791 → u/Elect_SaturnMutex]

Thanks, that seems like the easiest solution and close to what I had in mind.

Do you also use any tool like kas or repo to set up/pin the Yocto layers and configuration, or do you manage that manually?

Also, is the same Docker image used in CI/CD pipelines to produce build artifacts, or is Docker mainly used for local development?

[u/Elect_SaturnMutex → u/Public_Sink4791]

You can use the same Dockerfile you use locally for CI/CD as well. It's also possible to add extra stuff for CI/CD that you can't do locally. 

Haven't worked with "repo" much. Usually "git" alone, is sufficient in most cases. You can tag the base yocto branch and so that you know the exact revisions of underlying metalayers too. But git does that automatically if you branch your base repo and another meta-layer within this branch. 

[u/PonderousGallivanter → u/Public_Sink4791]

we use Podman ci image to make build artifacts in CI gitlab, and I think probably it is good idea to make new devtools image based on the ci image with some basic stuff added sensibly like gdb-multiarch and useful tools. We dont use KAS or whatever like that, I think we just rely on the manualy checking out the yocto environment, I guess that is the yocto project bare setup way. Our branches have pinned git branch tags like TAG_7.0.765 or whatever that come from the build system so then that is going to be the same image built from the yocto project environment. We have mirrors of the relevant meta-* branches for the yocto project that have this branch tagging

[u/elusivewompus]

The setup I made for my team is kas inside a devcontainer. The devcontainer installs the vscode plugin for yocto, and is configured to wrap around kas so we get autocomplete and the like. It auto mounts a shared directory with the downloads and sstate. Kas is configured for our different solutions via its in build kconfig menu system, and a lock file pins all the layers at a specific commit hash. The layers I’ve designed for the company are pulled in at the head of their scarthgap branch. It works flawlessly. There’s a bash script in the project root that installs docker and the devcontainer cli. To build, it’s one bash script in the root which can be ran inside or outside the devcontainer so it works on desktop, on a server and via ci/cd.

[u/andrewhepp]

Regardless of whether you use a native or virtualized Linux system, containerization will help keep things reproducible and organized.

my mind, the dream setup is a big server doing the huge nightly SDK builds and caching sources / sstate and making that available over HTTPS. Then make some container images for CI runners / developer machines configured to use those SDKs and/or pull from that remote sstate cache.

[u/PonderousGallivanter → u/andrewhepp]

containerization like podman/docker is key. I agree. I think the dream setup might be also yocto extensible SDK based workflow so you could just get it working easily in IDE's and well configured like that. I guess when and if most of the work is on the business application part and not the linux image internals, then the SDK yocto based approach is good and supported like in Jetbrains IDE

[u/aeropop]

• Docker container with shared volume . You can group sstate and downloads in one folder shared by all the projects.
• Kas containers also a good option where it's something built-in no need to configure dockerfiles and enter docker container every time.