Skip to content

ci: qemu runtime tests for vscode-weston-launcher#6

Merged
EmbeddedAndroid merged 1 commit into
mainfrom
qemu-runtime-tests
May 14, 2026
Merged

ci: qemu runtime tests for vscode-weston-launcher#6
EmbeddedAndroid merged 1 commit into
mainfrom
qemu-runtime-tests

Conversation

@EmbeddedAndroid

Copy link
Copy Markdown
Owner

Adds end-to-end runtime tests that boot a Yocto image with vscode + vscode-weston-launcher under QEMU and verify the integration actually works.

OEQA test cases (lib/oeqa/runtime/cases/vscode_launcher.py):

VSCodeLauncherInstallTest

  • weston.ini contains the meta-vscode-launcher-begin sentinel (postinst worked)
  • /usr/share/vscode/bin/code is executable and the icon PNG is present
  • code --version exits 0 (smoke test for binary + libc/libstdc++ resolution)

WestonStartedTest

  • weston process is running within 30s of boot
  • /run/user/*/wayland-0 socket exists

VSCodeWaylandLaunchTest

  • VSCode launches against the live wayland-0 socket (--no-sandbox, /tmp scratch dir)
  • Process is still alive 20s later
  • Process has wayland-0 in its fd table (proves it actually connected to weston)

Workflow (.github/workflows/qemu-runtime.yml):

  • Weekly cron Sunday 03:17 UTC + workflow_dispatch
  • ubuntu-22.04 hosted runner with KVM
  • Builds core-image-weston with vscode + vscode-weston-launcher + wayland-utils
  • INHERIT += "testimage" + TEST_SUITES = "ping ssh vscode_launcher"
  • TESTIMAGE_AUTO=1 fires do_testimage at end of build automatically
  • ~1-3 hours from cold sstate; weekly cadence keeps it sustainable
  • Caches poky checkout + sstate (10 GB cap) + downloads

Doesn't run on PRs (too expensive); manual dispatch is available for iteration. If this becomes a bottleneck a self-hosted runner on the build server can be added in a follow-up.

The launcher-click side of "launches from the weston panel" (UI input injection via wlrctl/ydotool) isn't covered here — that's tracked separately as Phase 3.

Adds:

- lib/oeqa/runtime/cases/vscode_launcher.py: OEQA test suite that
  is auto-discovered when this layer's bitbake-layers add-layer
  runs. Tests:
    VSCodeLauncherInstallTest
      .test_weston_ini_has_launcher       (postinst worked)
      .test_vscode_binary_is_executable
      .test_vscode_cli_version            (code --version exits 0)
    WestonStartedTest
      .test_weston_process_running        (pgrep weston after boot)
      .test_wayland_socket_present        (/run/user/*/wayland-0)
    VSCodeWaylandLaunchTest
      .test_vscode_starts_on_wayland      (launch code against the
                                           wayland socket, wait for
                                           it to settle, verify the
                                           process is alive and has
                                           wayland-0 in its fd table)

- .github/workflows/qemu-runtime.yml: weekly cron (Sun 03:17 UTC)
  plus manual dispatch. Builds core-image-weston with vscode +
  vscode-weston-launcher + wayland-utils, INHERIT += testimage with
  TEST_SUITES = ping ssh vscode_launcher. Auto-fires do_testimage
  at the end of the build, which boots the image under qemu (with
  KVM acceleration from the GHA runner) and runs OEQA via ssh.

Heavy CI: ~1-3 hours from a cold sstate. Weekly cadence keeps it
sustainable; manual dispatch for iteration. Self-hosted runner on
fio can be added later if we want faster turnarounds.
@EmbeddedAndroid EmbeddedAndroid merged commit 261bf59 into main May 14, 2026
22 checks passed
@EmbeddedAndroid EmbeddedAndroid deleted the qemu-runtime-tests branch May 14, 2026 22:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant