[libcamera-ci,RFC,v1,0/5] on-device-testing proof of concept
mbox series

Message ID 20260119102039.3521673-1-barnabas.pocze@ideasonboard.com
Headers show
Series
  • on-device-testing proof of concept
Related show

Message

Barnabás Pőcze Jan. 19, 2026, 10:20 a.m. UTC
This adds the necessary gitlab parts for running lc-compliance via
lava on a "real" device, specifically a debix-a board with an imx219
sensor.

There are three parts to the process:

1. libcamera is cross-compiled to the target architecture.
   This uses a separate container, and does not use setup-container.sh.

2. A debian root file system is built, appropriate for running
   libcamera as compiled in (1).

3. LAVA job is submitted to the lava worker to run `test-libcamera.sh`
   on the device.

Couple points:

1. While building debian root filesystem is integrated in the pipeline,
   manual intervention is needed. It must be uploaded to the lava worker's
   local container registry. Either one has to build the image locally
   or pull it from the gitlab container registry; and then upload it to the
   local registry. Specifying which container image the device should use is
   not implemented at the moment, it is hard-coded on the device itself.
   The jobs are triggered manually, so this is conveniently doable before
   the actual testing starts.

   Nonetheless I think be very nice if this could be fully automatic.

2. The cross compilation and rootfs generation both use their own separate containers,
   and separate setup processes not integrated with setup-container.sh. To be honest
   I find that whole mechanism is a unfortunate, I feel like it already multiplexes
   too many things.

3. lava-gitlab-runner can only use files from artifacts and not from
   the repository (https://github.com/collabora/lava-gitlab-runner/issues/16),
   so there is a job `lava-jobs-as-artifacts` for that. Although even if it
   could, the libcamera ci definitions are in a separate repository, so that
   would most likely still not work.

4. The cross compilation jobs saves the url of the debian package artifact
   in a `dotenv` artifact report, for lava-gitlab-runner to access it, and for
   it to be accessible on the device to download and install the package.

   This is needed because there does not appear to be a way to download job
   artifacts based on the (pipeline id, job name) tuple, same applies to getting
   the job id from another job. At least without more complex use of the gitlab api.

   But this means that the lava job must get the artifacts from the cross compilation
   job, which unfortunately means downloading the deb package unnecessarily.

5. The camera id is hard-coded in the lava job definition. Maybe it could be better
   to extend lc-compliance to support camera indices.

Barnabás Pőcze (5):
  Add job to generate container for cross compilation
  Add job to build deb package for libcamera
  Add job to build debian rootfs
  Add job to run lc-compliance via lava
  Guard jobs required for hardware testing

 .gitlab-ci/build-debian-rootfs.sh             |  79 ++++++++
 .../opt/test-libcamera.sh                     |  18 ++
 .gitlab-ci/on-device-testing/lava-debix-a.yml |  40 ++++
 .gitlab-ci/setup-debian-cross-container.sh    |  45 +++++
 gitlab-ci.yml                                 | 180 ++++++++++++++++++
 5 files changed, 362 insertions(+)
 create mode 100755 .gitlab-ci/build-debian-rootfs.sh
 create mode 100755 .gitlab-ci/debian-rootfs-overlay/opt/test-libcamera.sh
 create mode 100644 .gitlab-ci/on-device-testing/lava-debix-a.yml
 create mode 100755 .gitlab-ci/setup-debian-cross-container.sh

--
2.52.0