Build your Yocto images on CRACI

Why Yocto builds are hard to run in CI

A full image build compiles a toolchain, a kernel and hundreds of packages from source. On the standard 2-core runners most CI services offer, that can take hours, so many embedded teams keep a dedicated build server under a desk or in a rack, and that server becomes one more machine to patch, back up and explain to an auditor.

A Yocto build also downloads a great deal: source tarballs, Git repositories and patches from upstream projects and mirrors. Those downloads are exactly what the Cyber Resilience Act asks manufacturers of connected devices to know about and keep track of.

What CRACI gives a Yocto build

Runners sized for BitBake

CRACI runners scale from 1 to 32 compute units, where each unit is 1 vCPU and 3 GB of RAM. A Yocto build can ask for the largest size, 32 vCPUs and 96 GB of RAM, from the workflow itself. Jobs run in isolated virtual machines and the runs still appear in GitHub like any other Actions job.

Minutes are metered per second and billed per vCPU-minute, so a large runner costs more per minute and finishes sooner. See pricing for current rates.

Network access you decide

BitBake can already restrict its fetcher to a list of hosts with BB_ALLOWED_NETWORKS. CRACI adds a second control at the runner: an egress policy that is checked before the job starts and fails closed, so a recipe, a script or a compromised tool that goes around the fetcher still cannot reach a host you did not allow. Policy violations can be sent to you by email.

A record of what the build fetched

CRACI observes the traffic a job sends to package and source hosts and records it as build evidence. For a Yocto build that means an independent account of the sources that actually came over the network, next to the SBOM that Yocto writes itself. Sources BitBake fetches from the Yocto source mirror are recorded in the CRACI job SBOM.

CRACI and the Yocto SBOM

Yocto already generates an SPDX SBOM for your image through its create-spdx class, describing the components you used, their licenses, sources, dependencies and applied patches. That document is built from recipe metadata and is the right place to start. CRACI does not replace it.

What CRACI adds is evidence from outside the build system: what the runner saw the job download, where from, and under which network policy. When an auditor or a customer asks how you know the SBOM matches what was built, you can point to a record the build could not edit.

A minimal workflow

The Yocto example in the CRACI docs builds core-image-sato for qemux86-64. The parts that matter for CRACI are the runner size and a fetcher configuration that uses the official Yocto source mirror:

jobs:
  build:
    runs-on: craci
    steps:
      - uses: cracicorp/setup@v1
        with:
          size: "32"
      # install the host packages from the Yocto quick start, then:
      - run: |
          echo 'SOURCE_MIRROR_URL = "https://downloads.yoctoproject.org/mirror/sources/"' >> conf/local.conf
          echo 'BB_ALLOWED_NETWORKS = "downloads.yoctoproject.org"' >> conf/local.conf
          bitbake core-image-sato

The docs guide has the full workflow, including host dependencies and locale setup, and the runner configuration reference lists every setup option.

Things to know

• Builds run on CRACI's managed runners from GitHub Actions. Customer-hosted runners are not offered, and GitHub Actions is the supported CI integration.
• Point BitBake at mirrors CRACI can see, such as the official Yocto source mirror, rather than arbitrary hosts. The docs guide shows a working setup.
• Keeping the downloads directory and shared state cache between runs is what makes repeat builds fast.
• Native ARM64 runners are available at the same rate as x86-64, with limited capacity.

Building connected devices for the EU market? Read what the CRA requires, and how CRACI works for industrial IoT and consumer electronics.