ES: KAS — Simplified Yocto Build Management

Managing a Yocto build with multiple layers from different Git repositories can become complex. Cloning each repository manually, keeping versions aligned, and configuring the build directory consistently across different machines is tedious and error-prone. KAS (Kick-Ass Setup) solves this with a single YAML-based configuration that defines everything needed to set up and run a Yocto build.

What is KAS?

KAS is a build tool that:

• Reads a YAML configuration file defining all required repositories and their versions
• Clones and checks out all required layers automatically
• Configures the build environment
• Optionally runs the build in a Docker container for full isolation

Without KAS:
  git clone poky
  git clone meta-openembedded
  git clone meta-raspberrypi
  git clone meta-myproduct
  source oe-init-build-env
  (manually edit bblayers.conf and local.conf)
  bitbake core-image-minimal

With KAS:
  kas build project.yml

Why Use KAS?

1. Centralised Configuration

A single YAML file defines all layers, repositories, branches, and commit hashes. No more maintaining multiple git clone scripts or README instructions.

2. Multi-Repository Support

KAS manages layers from multiple different Git repositories in a single operation — each with its own URL, branch, and pinned commit.

3. Reproducibility

By specifying exact branches, tags, or commit hashes in the YAML file, KAS ensures that every developer and CI/CD system builds from exactly the same source code.

Traditional approach: "works on my machine"
KAS approach: identical builds on every machine

4. Containerised Builds

KAS integrates with Docker, allowing builds to run in an isolated container with a known-good build environment. This eliminates host machine configuration issues.

5. Simplified Workflow

Teams can focus on development rather than spending time on build system setup and configuration. New developers can be productive on day one.

KAS YAML Configuration

A KAS configuration file defines:

• Repositories — where to find each layer, which branch or commit to use
• Build system — which environment initialisation script to use
• Configuration — local.conf settings, bblayers.conf additions

Minimal KAS YAML Example

header:
  version: 1

repos:
  poky:
    url: https://git.yoctoproject.org/git/poky
    refspec: kirkstone

  meta-openembedded:
    url: https://github.com/openembedded/meta-openembedded
    refspec: kirkstone

  meta-layer:
    url: https://github.com/example/meta-layer
    refspec: master

build_system:
  env: poky

YAML Key Fields

Extended KAS Configuration

A more complete configuration that pins exact commits and adds local configuration:

header:
  version: 1

machine: raspberrypi3
distro: poky
target: core-image-minimal

repos:
  poky:
    url: https://git.yoctoproject.org/git/poky
    refspec: scarthgap
    layers:
      meta:
      meta-poky:
      meta-yocto-bsp:

  meta-raspberrypi:
    url: https://git.yoctoproject.org/meta-raspberrypi
    refspec: scarthgap
    layers:
      meta-raspberrypi:

local_conf_header:
  myconfig: |
    ENABLE_UART = "1"
    IMAGE_INSTALL:append = " openssh"

Installing KAS

Via pip

pip install kas

Via apt (Debian/Ubuntu)

sudo apt install kas

Using KAS

Fetch Repositories and Run the Build

kas build file-name.yml

This command:

1. Reads the YAML configuration
2. Clones or updates all defined repositories
3. Configures the build environment
4. Runs BitBake to build the specified target

Use Docker for Isolation

kas-container build file-name.yml

This runs the entire build inside a Docker container using the official KAS container image, which contains all required host build tools and dependencies.

Build a Specific Recipe

kas shell project.yml -- bitbake python3-mypackage

The kas shell command sets up the environment without building, then passes additional commands after -- to run in that environment.

KAS in a CI/CD Pipeline

KAS is particularly useful in continuous integration pipelines because it makes the build completely self-describing:

# .gitlab-ci.yml example
build:
  image: ghcr.io/siemens/kas/kas:latest
  script:
    - kas build project.yml
  artifacts:
    paths:
      - build/tmp/deploy/images/

The same project.yml used by developers is used by the CI system — guaranteeing identical results.

Final Thoughts

KAS transforms Yocto build setup from a multi-step manual process into a single command. For teams working on complex embedded Linux products with multiple layers and strict version requirements, KAS is an essential tool.

KAS Workflow:
Write project.yml
    (define repos, branches, machine, target)
        |
        v
kas build project.yml
    (KAS clones repos, configures env, builds)
        |
        v
Deployable images in build/tmp/deploy/images/

If you are managing a Yocto project with more than two or three layers, KAS is worth adopting. It pays back its setup cost within the first week of team use.