KernelCI configuration for CIP SLTS: what practitioners need to know

At a glance

What this is: This is a practical guide to wiring KernelCI into CIP SLTS testing, with the key finding that board metadata, scheduler entries, and lab setup must stay aligned or automated coverage fails.

Why it matters: It matters because release confidence in embedded Linux depends on trusted test orchestration, and identity and access teams can recognise the same governance pattern in any system where configuration drift breaks policy enforcement and control coverage.

Context

KernelCI is a continuous integration and boot-testing system for Linux kernels, and CIP SLTS uses it to validate long-term support builds against the right hardware. The operational problem is not just adding a board, but making sure the platform profile, scheduler rules, and lab environment describe the same device.

In practice, the control gap is metadata drift. When the board definition in KernelCI does not match the device connected to lava, tests may run but they no longer prove what the programme thinks they prove. That is a governance failure in the test pipeline, and the same pattern appears in identity and access programmes when inventory and policy disagree.

Key questions

Q: Why do KernelCI tests fail when board metadata and lab setup drift apart?

A: KernelCI depends on the platform definition, scheduler entry, and lab target all describing the same board. If the compatible strings or runtime routing no longer match the physical device, jobs may still run but the results no longer prove what the team thinks they prove. The failure is assurance drift, not just a broken script.

Q: How should teams govern new board onboarding in KernelCI?

A: Treat board onboarding as a controlled configuration change. Validate the platform entry, the extracted compatible strings, and the scheduler rule together, then confirm the lava target actually matches the declared profile before relying on the test output.

Q: What breaks when a KernelCI platform is defined but never scheduled?

A: You get apparent coverage without executed coverage. The board exists in configuration, but if the job is not routed to the correct runtime and platform list, no boot test is actually exercising that hardware path, so release confidence is overstated.

Q: What is the difference between KernelCI platform metadata and scheduler configuration?

A: Platform metadata describes the device identity and compatibility, while scheduler configuration decides when and where the test runs. Both are required: one names the target, the other makes execution happen. If either side is wrong, automated validation loses reliability.

Technical breakdown

How KernelCI maps a board to the right test target

KernelCI uses platform definitions to decide which hardware profile a job should run against. In this article, the board is added to a platforms.yaml file with machine, device tree, and compatible string data, then paired with the scheduler so jobs are routed to the matching lava environment. The compatible string extraction step matters because it turns kernel metadata into a machine-readable selector for the test pipeline. Without that alignment, automated testing can attach the wrong board profile to the job and the results lose operational value.

Practical implication: treat platform metadata as a control surface, not a documentation artifact, and verify that every board profile resolves to one intended device type.

Why scheduler entries matter as much as platform entries

The scheduler defines which jobs fire, on which runtime, and against which platform list. In the CIP example, a job entry points to a specific arm64 board and a lava runtime, then uses the scheduler to launch the build and boot flow in sequence. That separation is important because board enablement is only useful if the job orchestration can actually dispatch the test at the right stage. Configuration drift here can leave a board defined but never exercised, which creates false confidence in coverage.

Practical implication: validate the scheduler path whenever you add or change a board, because a defined platform without a runnable job is not test coverage.

What lab orchestration adds to governance of automated testing

The article shows that KernelCI coverage depends on the lab environment being able to host the device and execute the boot test workflow. Tools such as lava and lava-docker provide the execution substrate, but the governance issue is whether the lab, platform file, and scheduler all represent the same test boundary. That is the same kind of control coordination seen in other automation systems: provisioning, routing, and execution must agree or the pipeline becomes misleading rather than authoritative.

Practical implication: review the full test chain end to end whenever lab infrastructure changes, not just the board definition or the test job in isolation.

NHI Mgmt Group analysis

Configuration integrity is the real control here: KernelCI board enablement only works when metadata, scheduler logic, and lab execution describe the same asset. A device profile that is technically valid but operationally mismatched creates coverage theatre, where tests appear to run but no longer validate the intended hardware. Practitioners should treat this as a control integrity problem, not a documentation task.

Test infrastructure drift is a governance problem, not an engineering nuisance: The article shows how small mismatches in compatible strings or scheduler entries can disconnect policy intent from execution reality. That is the same structural failure seen in identity programmes when inventory, policy, and enforcement drift apart. Teams should manage test platforms with change control and review discipline.

KernelCI metadata behaves like an identity binding for hardware: The platform definition is what tells the system which board is allowed to receive which job. When that binding is wrong, automation still proceeds, but assurance collapses. The practitioner lesson is to make device identity in CI as explicit and reviewable as any other high-trust configuration.

Embedded release confidence depends on trustworthy orchestration: CIP SLTS depends on repeatable boot testing, so scheduler and lab setup must be governed as part of the release system. This is especially relevant where long-term support kernels underpin products that cannot tolerate silent coverage gaps. Practitioners should align CI governance with release assurance requirements, not treat them as separate disciplines.

What this signals

Configuration binding is the central control problem: KernelCI only provides meaningful assurance when hardware identity, test routing, and lab execution remain tightly bound. The same governance lesson applies in identity security, where authoritative inventory matters because enforcement is only as accurate as the objects it is attached to.

Device profiles deserve the same discipline as privileged identities: A board definition that can be changed casually becomes a source of silent assurance loss. Practitioners should apply review, change control, and traceability to CI platform files with the same seriousness they apply to high-trust access paths.

For practitioners

• Audit board-to-lab mapping before enabling a new device Confirm that the platforms.yaml entry, compatible strings, and connected lava target all point to the same hardware profile before scheduling tests.
• Validate scheduler routing for every new KernelCI job Check that the job entry, runtime selection, and platform list produce a runnable path rather than a defined but inactive configuration.
• Compare extracted compatible strings with kernel source Use the compatible extraction workflow to verify that the platform definition matches the board files in the kernel tree you plan to test.
• Treat lab setup changes as release-governed changes Review lava and any containerised lab dependencies whenever hardware, scheduler rules, or kernel branches change so the test boundary stays accurate.

Key takeaways

• KernelCI board onboarding is a governance exercise as much as a build task, because the platform definition must match the lab target for results to mean anything.
• The main risk in CIP SLTS integration is configuration drift between metadata, scheduler routing, and hardware reality, which creates false confidence in automated testing.
• Practitioners should validate the full test chain whenever they add or change a board so release assurance stays tied to the intended device profile.

Key terms

• Platform Definition: A platform definition is the structured description of a test target, including board identity, architecture, and compatibility data. In KernelCI, it tells the scheduler which hardware profile a job should use so automated results map to the intended device rather than an arbitrary lab node.
• Compatible String: A compatible string is a device descriptor used by the Linux kernel and related tooling to identify hardware support. In KernelCI onboarding, it helps map a board definition to the correct platform entry and test target.
• Scheduler Routing: Scheduler routing is the logic that decides which job runs, when it runs, and on which runtime or platform. In CI systems like KernelCI, it is the control that turns a configuration record into an executed test, so mistakes here directly affect coverage reliability.
• Lab Orchestration: Lab orchestration is the coordination of hardware, software, and execution services needed to run automated tests. It includes the test runner, the lab backend, and any containerised environment used to connect jobs to real devices, making it a governance issue as well as an engineering one.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners building controlled automation. It gives security and infrastructure teams a shared governance language for trust, inventory, and lifecycle control.