Skip to content

ci: db410c bare-metal testing

Emma Anholt requested to merge anholt/mesa:ci-db410c-baremetal into master

Since we had to bail on LAVA due to corporate restrictions on the AGPL, we figured I should do a quick check out how hard it is to do what LAVA was doing on our own.

Turns out, pretty easy. First, things I don't like with it:

  • Configuration of runners bleeds into the repo more. If I want to, say, change how we access the consoles in the future, I have to make those changes in .gitlab-ci instead of in the runner's config. On the other hand, it means we can safely experiment more without pausing the farm.
  • Still doing this in arm_build instead of x86_build, which means that we are doing all the gitlab-runner job work under qemu.
  • Passing all the devices (console serials and usb) into each runner's container. I'd rather be running without --privileged, but since fastboot serial shows up after container start, you can't expose it with --devices.

On the other hand, there are some big advantages:

  • No more having to stuff the initramfs/kernel into the artifacts so LAVA can find it! Huge bandwidth/artifacts size win.
  • Boards are visible in gitlab's web UI (you can easily see what board is scheduled in the user's UI, and admins can pause/unpause).
  • No easy-to-mix-up synchronization of board count between gitlab-runner's limit= setting and the number of boards currently running in the LAVA server.
  • We have complete control of the boot process (why was LAVA rebooting my board twice while booting it? because it doesn't know state between deploy and boot so it would reset into fastboot each time).
  • Fewer places to misplace our env vars (gitlab-ci var -> lava-gitlab-ci.yml script -> generate_lava.py -> lava-deqp.jinja2 is now gitlab-ci var -> fastboot.sh -> init.sh)

TODO (not necessarily before merge):

  • Register the rest of the db410c boards as runners
  • Make a variant for depthcharge on cheza
  • Move to x86_build

Merge request reports