Debian support - #30
Conversation
4cd8358 to
0291167
Compare
|
I based it on top of #31 which should be merged first. |
Loïc Minier (lool)
left a comment
There was a problem hiding this comment.
Unrelated to your PR, but FYI there's a typo in the filename: lava_test_plans/testcases/pre-merge-dispaly-gfx.yaml (dispaly instead of display)
Left a few other comments from a quick pass on the changes
a6a95e1 to
11a9999
Compare
11a9999 to
b8f7021
Compare
Thanks. This is now fixed. |
73db89c to
7e6e142
Compare
ea8bbe1 to
da6b5d9
Compare
Christopher Obbard (obbardc)
left a comment
There was a problem hiding this comment.
This looks good shape to me so far - but needs care to make sure we include all boards/tests from https://github.com/qualcomm-linux/qcom-deb-images/tree/main/ci/lava
I didn't review in too much detail as Milosz Wasilewski (@mwasilew) said he will rebase first.
021584c to
eb386be
Compare
81d8003 to
cd66703
Compare
| {% set qdl_rootfs_image = "disk-sdcard.img2" %} | ||
| {% set qdl_tarball = "flash-emmc.tar.gz" %} | ||
|
|
||
| {# WiFi_OnOff needs iw, which the testkit has no debian package mapping for. #} |
There was a problem hiding this comment.
Would it make sense to track these workarounds as issues and add links?
Also since you have them repeated in multiple files, would it make sense to have some kind of include to include the workaround and maintain it in one place?
I am not sure if this would be too much rework now, so I would be happy if you wanted to create an issue to do it as follow-up work later :-)
# devices/common/debian-excluded-tests.jinja2:
{% set EXCLUDED_TESTS = [
'WiFi_OnOff',
'AudioRecord',
'Docker_Kernel_Config',
'Kubernetes_Kernel_Config',
'Logging_Journalctl_Validation'
] %}
{% set EXCLUDED_TESTPLANS = [
'pre-merge-bt.yaml',
'pre-merge-audio.yaml',
'pre-merge-display-gfx.yaml'
] %}
# each file:
{% from "devices/common/excluded-tests.jinja2" import
EXCLUDED_TESTS,
EXCLUDED_TESTPLANS
%}
There was a problem hiding this comment.
If these are going to be the same for all boards, I'm happy to convert them to include file. The overall idea is that exclusions are tracked per board. I guess we should rather track board/kernel combo, but there is no infrastructure for that yet.
There was a problem hiding this comment.
cd66703 to
904c982
Compare
A board can need a named device command run once the image has been deployed and before the OS is booted - bringing up the lab network switch port, for instance. There was no way to ask for one: pre_boot_commands.jinja2 only knows the fixed pre_os_command and pre_power_command names. Add user_pre_boot_commands, a list of device command names, to master.jinja2 so every deployment method gets it. It defaults to empty, so nothing changes for a device that does not set it. For it to sit between deploy and boot, master.jinja2 now lays out the whole action list - deploy_target, pre_boot_command, user_pre_boot_commands, boot_target, post_boot_command and test_target - and the fastboot, flasher, qdl, nfs and qemu templates fill in those blocks instead of overriding actions. Only fastboot still extends actions, to append its test_lxc block after the tests. qdl flashing is part of the deployment, so its qdl boots move into deploy_target and the commands run after the board is flashed. The rendered jobs are unchanged for every device and test plan covered by the test suite. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
Becoming the super user was hardcoded as su, which assumes the root account has a password of its own to ask for. An image can instead give the login user sudo and leave root locked, and there was no way to say so. Take the command from AUTO_LOGIN_SU_COMMAND, defaulting to su, so nothing changes for an image that does not set it. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
An image can ship an expired password and make the first login set a new one before it gives out a shell. Nothing here could drive that exchange: auto_login_commands.jinja2 only knows how to become root, so a project had to override the whole block and spell the prompts out in its own BOOT_OS_PROMPT. Answer it here instead. AUTO_LOGIN_NEW_PASSWORD, when set, replies with the current password and then the new one twice, and boot_os_prompt adds the three prompts that exchange has to be matched on. Both are skipped when it is unset, so nothing changes for an image that does not force a change. The rendered jobs of every other project are byte identical. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
The project rendered its jobs through include/flasher.jinja2. Move to
native LAVA qdl deploymen which allows multi storage flashing.
Render the same deployment here. include/qdl.jinja2 already carries the
multi-stage flashing logic and the common devices already carry each
board's firehose programmer, rawprogram/patch lists and stages, so the
project template only has to add what is specific to a debian image: the
authenticated download, the <suite>[-<variant>]-flash-<storage>.tar.gz
tarball name, the disk-{ufs,sdcard}.img2 rootfs image, and the answers to
the password change the first login forces.
Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
Only the build URL was recorded, so a job could not be traced back to the pull request or the workflow run that produced the image under test. Emit the same named keys meta-qcom does. They are always rendered, empty when unset, which keeps a query written against one of them meaningful whichever project rendered the job; anything further a caller wants to record still rides along in EXTRA_METADATA. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
The project had a single flat boot.yaml and no functional testing at all: not one qcom-linux-testkit test ran against a debian image. Lay the plans out as <project>/<distro>/<plan>, the structure every other project uses and the one the test-distro workflow expects, and add a pre-merge plan alongside boot. The pre-merge plans are the existing testcases, the same ones meta-qcom runs: basic, bluetooth and display. A test plan is resolved by file name, so linking them is enough to render them, and the tests a board cannot run report SKIP rather than FAIL. The bluetooth, audio and display plans are then excluded on every board. They ask for a lab fixture through a LAVA tag, and a job whose tag no device carries does not fail, it waits: it sits queued until the workflow gives up on it, on every board, every run. Excluding them per board rather than leaving them unlinked keeps the entry to delete in view of whoever gives a board the hardware. Note that pre-merge-basic still names the Ethernet suite as one test, which qcom-linux-testkit split into seven after testkit-2026.08.23. A caller has to pin a revision no newer than that until the testcase is updated. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
A test case reads the list as EXCLUDED_TESTS|default([]), which resolves against the render context. A device that sets it as a template variable is only seen when inheritance happens to carry it that far, and whether it does depends on how the device was named on the command line: it works for a bare name resolved through --testplan-device-path, and is silently dropped for the projects/<project>/devices/<machine> path form. Both the action in this repository and the one in meta-qcom use the path form, so every EXCLUDED_TESTS list in the tree - 18 devices across meta-qcom, meta-qcom-distro and qcom-deb-images - has been having no effect at all. EXCLUDED_TESTPLANS does not have the problem because it is lifted into the context explicitly; do the same for EXCLUDED_TESTS. Note this changes what is rendered for the devices that carry a list: the tests they name stop being rendered, which is what the lists were written to do. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
The board is boot tested by qcom-deb-images, through a job template of its own, and was the one board of that set with no device here. The common device flashes the first rawprogram/patch pair only. ptool describes two physical partitions for shikra-evk/emmc and emits a pair for each, the second being the JEDEC boot area that holds the CDT, so flash both and the board gets the CDT its build was generated against. The rendered job is identical to the template it replaces: same device type, deploy, flashing stage and login exchange. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
Drop tests and test plans that currently fail. Save the exclusion list into a common file as they are shared across all devices. The exclusions are tracked in qualcomm-linux/qcom-deb-images#647 Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>
904c982 to
d1139df
Compare
d77173d
into
qualcomm-linux:master
Add support for qcom-deb-images project: