Use cases

The LAA is already used for multiple purpose, this page will try to list the current use cases that we currently support.

A Gitlab (resp. Github) runner

The LAA can run a gitlab runner that will have full access to the attached DUT. The gitlab pipeline job is then able to directly test any part of the software stack on your DUT.

This has been used successfully to test IOT devices directly from a gitlab pipeline: check the FOSDEM 26 presentation.

Gitlab use case

Using the LAA as a Gitlab runner is a good fit for single developers to mid-size teams that want to add Hardware in the CI loop without having to setup a proper automation service like LAVA.

A KernelCI runner

The Linaro Automation Appliance can be configured from LMS to act as a KernelCI runner. The LAA will pull the KernelCI pull-lab api endpoint for new jobs for the attached DUT.

The LAA will then run the job on the attached DUT and report the result back to KernelCI API. This is an easy way to connect your DUT to the KernelCI API while keeping your DUT inside a closed network.

A LAVA worker

The Linaro Automation Appliance is a fully integrated LAVA worker that allows LAVA to run any jobs on your DUT.

The LAVA worker is fully configured from LMS, the fleet management software. You only need to specify the LAVA instance to use and the attached DUT. The Linaro Automation Appliance will be automatically configured to connect to your LAVA server.

LAVA use case

Using the LAA as a LAVA worker is a good fit for teams that want to have a solid and versatile automation framework that allows to manage a pull of DUTs in their lab. Linaro can help you to setup such lab.

Sharing your DUT with the LAA

The LAA is a great tool to share access to your DUT inside or outside your company.

Depending on the level of isolation and security that you want to have, you can either grant remote ssh access to the LAA to the user or only access to the LAA embedded api and website.

SSH access

By granting ssh access to the LAA, you give the user a full access to the LAA and the DUT. This is a powerful way to share the DUT usage but this also give full access to the network used by the LAA.

API access

By only giving access to the LAA API, you give full access to the DUT (and the DUT automation tools) while preventing the user to directly run any command on the LAA or to access the local network.

The user will be able to interact with the DUT but without having any control on the network used by the LAA.

API access

When granting only API access, you can grant remote access to your hardware to any users, including potential customers, while keeping your local network safe. In fact, the user will only be able to interact with the DUT and nothing else on your network.