One Yocto Pipeline for Four Device Lines: How an Audio Manufacturer Went from Manual Builds to Unattended Runs
A technical look at replacing a legacy build system with Docker-based Yocto builds, choosing cloud hardware, and handing the result to the people who own it.
Executive brief
- An audio manufacturer with four device lines moved from a legacy build system and manual builds to one Docker-based Yocto pipeline with GitHub CI/CD. Total build time went from 4 hours to 35 minutes.
- The work had six parts: Docker migration, build time optimization, cloud hardware selection, GitHub CI/CD, an infrastructure trial on Hostinger cloud followed by a move to Azure, and a documented handover.
- Builds now run unattended when triggered automatically, and on demand when someone needs a package.
- The Azure machine configuration was tuned with cost as a constraint, not only speed.
- The leadership team was trained to create builds and packages themselves, which is what keeps the pipeline from sliding back into manual work.
The starting point: a legacy build system and manual builds
The client is an audio manufacturer with four device lines, all built with Yocto. We're keeping the company unnamed, and it doesn't matter much for the story. The shape of the problem is common: builds came out of a legacy build system, a person had to start them by hand, and a full build took 4 hours.
Four hours changes how a team behaves. Nobody reruns a build casually when it eats half a working morning, so changes get batched, and a failure found late costs the rest of the day.
Manual builds add a second problem. A build only happens when the right person is free to start it.
What the engagement covered
Six workstreams, each with a different job to do.
| Workstream | What it meant in practice |
|---|---|
| Migration | Legacy build system replaced with Docker-based Yocto builds |
| Build time optimization | Tuning the builds, with total build time going from 4 hours to 35 minutes |
| Hardware selection | Choosing cloud hardware suited to Yocto workloads |
| CI/CD | GitHub-based pipeline supporting on-demand and automated builds |
| Infrastructure | A trial on Hostinger cloud with fine-tuning, then a move to Azure with an optimized, cost-aware machine configuration |
| Handover | Documentation and training so the leadership team can make builds and packages |
One number is confirmed and published here: 4 hours to 35 minutes. We haven't split it by workstream. The gain came from the combination, and a per-lever breakdown would be a guess.
Step one: containerizing the Yocto build environment
Yocto is picky about its host. Distribution packages, tool versions and small environment differences can change whether a build works at all. A legacy build setup tends to accumulate around one particular machine that happens to work, and nobody wants to touch it.
Moving the builds into Docker turns that machine's history into a file. The environment is defined once, in the container image, and behaves the same on a laptop, a trial server or a production VM. That also explains why the later infrastructure moves were cheap to make. The host only has to supply CPU, memory and disk, because the build environment travels with the image.
If you're new to the pieces, the Yocto Project documentation and the Docker documentation cover the fundamentals.
Build time and hardware: two problems that look like one
A Yocto build compiles a very large number of tasks, in parallel, and leans hard on cores, memory and disk. Slow builds usually have two separate causes. One is how the build is configured. The other is what it runs on.
A well-tuned build on the wrong machine is still slow. A big machine running a poorly tuned build just costs more to be slow. Both were worked on here, and that's where the 4 hours to 35 minutes came from.
The infrastructure path
| Stage | Purpose | Outcome |
|---|---|---|
| Hostinger cloud trial | Run the containerized builds on rented cloud hardware before committing | Fine-tuning of the build setup was done during the trial |
| Azure | Long-term home for the pipeline | Highly optimized machine configuration, chosen with cost in mind |
Cost was a real constraint, not an afterthought. An oversized build machine costs money every month, and an undersized one costs engineering hours every day. The right configuration sits where those two curves cross for your workload, and you only find that point by measuring.
That's the argument for a trial on rented hardware first. A wrong guess is cheap there, and you learn what the build actually demands before you sign up for anything long term. Microsoft's Azure virtual machine sizes page is a reasonable place to see how many configurations there are to choose from.
GitHub CI/CD for four device lines
The pipeline supports two modes. Automated builds run without anyone starting them, which is what "unattended" means in practice. On-demand builds cover the moments when someone needs a package for a specific device line right now.
All four device lines go through the same pipeline, and what changes from run to run is which one is being built. GitHub's CI/CD tooling, GitHub Actions, is the usual home for this kind of workflow.
Why one pipeline and not four? Compare what happens when something needs to change.
| Situation | Four separate pipelines | One shared pipeline |
|---|---|---|
| Fixing a build problem | Fix it up to four times, and hope the copies match | Fix it once |
| Updating the build environment | Four updates, four chances to drift | One image, one update |
| Adding a fifth device line | Copy a pipeline and edit it | Add a target to the existing one |
| Finding out what ran | Look in several places | One place |
A playbook you can reuse
This is the order we'd follow on a similar project, drawn from how this one went.
Baseline the legacy build
Record how long a full build takes and who has to start it. The 4 hours in this project only means something because it was measured.
Containerize the build environment
Move Yocto builds into Docker so the environment lives in a file and not in one machine's history.
Trial on rented cloud hardware
Run the containers on a cloud instance, measure, and fine-tune the build setup before deciding on production hardware.
Choose production hardware with cost in view
Pick the machine configuration that hits your build time target without paying for capacity you don't use. Here that meant Azure.
Wire up GitHub triggers
Set up automated builds for routine runs and on-demand builds for the times someone needs a package.
Hand over with documentation and training
Make sure the people who need the packages can create them without the engineers who built the pipeline.
Handover: the part that decides whether it lasts
Handover here meant proper documentation and hands-on training, aimed at the leadership team so they could make builds and packages themselves.
A pipeline that only its author can operate turns back into manual builds under a new name. Good documentation answers the questions people actually have: how to start a build, how to read a failure, how to get the package out. If a document can't answer those, it isn't finished.
How to read the numbers
The 4 hours to 35 minutes figure describes this client's builds, on this client's setup. It isn't a benchmark of Docker against no Docker, and it doesn't promise the same ratio for your layers, your machine or your caching.
The "before" also includes a legacy build system and manual starts, which is more than a slow compile. Treat the number as evidence that the combination of containerization, tuning, hardware selection and CI/CD can move a build a long way, and measure your own baseline before you promise anyone a target.
FAQ
Can Yocto builds run inside Docker?
Yes. In this engagement the legacy build system was replaced with Docker-based Yocto builds, so the build environment is defined in the container image and behaves the same on any machine that can run it.
How much faster were the builds?
Total build time went from 4 hours to 35 minutes. That figure comes from the combination of the Docker migration, build tuning and hardware selection, and we don't attribute it to any single change.
Can one pipeline build several device lines?
Yes. This client has four device lines, and they all go through one shared Yocto pipeline. What changes from run to run is which device line is being built.
Why trial on one cloud provider and then move to another?
A trial on rented cloud hardware shows what the build needs in cores, memory and disk before you commit. Here the trial ran on a Hostinger cloud, with fine-tuning done during the trial, and the production infrastructure then moved to Azure with a machine configuration optimized with cost in mind.
Can GitHub start Yocto builds on demand and automatically?
Yes. The CI/CD setup on GitHub supports both: automated runs that need nobody to start them, and on-demand builds for when someone needs a specific package.
Who runs the builds after handover?
The client's leadership team. Handover included documentation and training so they can create builds and packages themselves.
Still starting Yocto builds by hand, or waiting hours for each one?
Tell us how many device lines you build, what your current setup looks like and how long a full build takes. We'll tell you where we'd start.
Talk to Stonetusker about your build pipelineRelated reading: Stonetusker Systems services