Comparing changes

Replicate build on push in the next branch. This will help testing the workflow changes. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

Signed-off-by: Mark Matyas <mmatyas@qti.qualcomm.com> Signed-off-by: Ricardo Salveti <ricardo@foundries.io>

Bring in new Ethernet inventory, traffic, throughput, and suspend/resume validation; interconnect and memory integrity tests; RMTFS storage and MinkIPC/QTEE PKCS11 validation; KVM test plans; SMP2P and enhanced remoteproc health checks; and Shikra audio routing updates. Also include gstreamer probe hardening (bounded hardware probes, codec fault classification from dmesg, treating unbound codec drivers as faults), Bluetooth first-boot recovery and scan/pairing stabilization, weston-simple-egl clock-step hardening, URM tests via Debian packages, and a Wi-Fi fix ignoring recoverable QMI DMA allocation fallbacks. Assisted-by: Claude Code:claude-fable-5 Signed-off-by: Ricardo Salveti <ricardo.salveti@oss.qualcomm.com>

Some tests are known to fail on a given device and their failure is accepted for the time being, usually because the fix belongs to another component and is already tracked in an issue. Until now the test job summary reported them like any other failure, so every run showed the same red cells and the reader had to remember which of them were already known. A genuine regression was easy to miss among them. Add a list of known failures per tested build variant under .github/known-failures, keyed by LAVA device type, where "*" stands for every device of the variant. Each entry carries the test name and a comment naming the issue the failure is tracked in, so that the list stays reviewable and does not turn into a pile of unexplained names. Apply the list when the summary is rendered: a listed failure is reported as a known failure and counted like a pass, and a test that passes although it is listed is reported as an unexpected pass and counted as a failure. The second half is what keeps the lists honest, as an entry that is no longer needed makes the summary fail until it is removed. The applied entries are listed with their comments in a section of their own below the results table. The list is picked by name from the distro and its suffix, so a new build variant gets its own list without any further wiring. Take that list from the pull request under test rather than from the base branch. The test chain runs on workflow_run, so its own checkout is the base branch and the list found there is the one already merged, which would leave a pull request that fixes a listed failure reported against a stale list until it lands. Check the lists out a second time from the branch or fork the pull request is built from, sparsely and read only as data, everything the chain runs still coming from the base branch. A run with no pull request behind it, and a fork that is no longer reachable, keep using the list of the checkout. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

The test job summary is not the only place a failure is reported. The LAVA JUnit files are published as the "Test Results" check, which fails on any failed test case, so an accepted failure kept that check red no matter what the summary said. The check is the one that gates a pull request, which made the lists of little use on their own. Rewrite the result files before they are published. A failure that is on the list of its build variant becomes a skipped test case, JUnit having no better way to express an expected failure, so it no longer fails the check while staying visible in the report. A test case that passes although it is listed becomes a failure, matching what the summary reports and asking for the entry to be removed. The comment of the entry is appended to the message of the rewritten test case, so the issue is one click away from the report. A result file is mapped to a variant and a device through its name, the one lava-test-plans builds. The lists come from the branch or fork the pull request is built from, like the ones the summary applies; both checkouts this needs have to happen before the artifacts are downloaded, as they would otherwise wipe them from the workspace. The lists are only read at the end of a test run, hours after a change to them was pushed, and an entry naming a variant or a device that is not tested is not an error at that point, it is simply never applied. Such a list looks like it suppresses a failure while the check stays red. Validate the lists on every change to them instead, against the build variants and devices the test workflow really tests. That last check belongs to the branch the lists live on, not to the lists themselves, so it is not one to make of a list coming from a pull request: such a list may well add or drop a variant. Add --syntax-only for that case, checking that the lists are well formed and no more, and fall back to the lists of the base branch when they are not - a list that does not even parse would otherwise abort the run publishing the results. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

The repository documents how to build an image but not what happens to it afterwards. Which build variants are tested on hardware, on which devices, and where to look for the results is spread over the workflow files, and the known failures lists that were just added have no entry point other than the README next to them. Add TESTING.md, describing when the tests run, the three build variants that are tested and the devices each of them covers, the boot and pre-merge stages, and the three places the results are reported. Give the known failures a section of their own, from adding an entry to what it changes in each report and why an entry that is no longer needed makes the check fail. Link it from the README. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

The result cells of the summary table linked to the resource_uri the LAVA API reports for a test case. That is the API endpoint of the test case itself: following it returns a JSON document restating the result that was just read from the table, over plain http, and leaves the reader to find the job and the failure in it by hand. The job log renders every line as an element with an "L<n>" id and offers a link to it, and the API reports the log line a test case was recorded on. Build the link from those instead, so that a result in the table leads straight to the line the test reported it on, with the output of the test around it. A boot job has no test case to point at, so link it to its log rather than to its results page, the log being what a boot failure has to be read from anyway. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

The lists were added empty, with nothing but their format documented, so neither the test job summary nor the "Test Results" check suppressed anything yet. Seed them from what the lab actually reports. The sample is the five most recent Nightly Build runs on master whose compilation stage passed in full, i.e. whose build-nightly jobs all The comments are left empty on purpose. Every entry still needs the issue it is tracked in before the list can be called reviewed, and the validation workflow already warns about each one that has none. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

This is the last tag that is in line with current version of lava-test-plans. 2026.08.30 breaks the test jobs generated with lava-test-plans. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

Navigation Menu

Uh oh!

Comparing changes

Open a pull request

Uh oh!

Commits on Sep 3, 2026

This comparison is taking too long to generate.

Uh oh!