Installing canonical-certification-client or canonical-certification-server is enough to get the full stack of dependencies.
Moreover the old commands were still referring to the plainbox-prefixed package names.
* Remove mention of checkbox-provider-certification-client in the install steps
Revamp Metabox Source Container (formerly known as Venv Container) (#305)
* Rework the Source Container Machine
The ContainerVenvMachine class used python virtual environments to
install Checkbox inside a container. It is renamed
ContainerSourceMachine and now deploys Checkbox directly into the
container using pip.
It now handles the creation of a systemd service, so that the service
container can be restarted, it will become reachable as soon as the
container is up.
It also copies over the following providers, so they can be used in
scenarios:
- base
- resource
- certification-client
Note that since Checkbox is now a monorepo, the `uri` parameter of the
configuration file has to point to the root of the Checkbox monorepo and
not to the checkbox-ng directory.
* Remove unnecessary parentheses in some Metabox modules
* Add jq as a dependency
jq is required for some JSON attachment jobs.
* Exit with error message if pylxd cannot create a client
* Send content of service directly in the container
Use textwrap.dedent() to prepare the content of the service file in a
more readable way, and put this content into a file directly instead of
relying on a bash command to avoid having to deal with escaping special
characters.
* Pass exception message (if any) when ClientConnectionFailed raised
5faa71e...
by
Pei Yao-Chang <email address hidden>
Add manifest for touchpad-related jobs (#293)
The original jobs appear and be executed based on the Chassis type from
DMI information. However, there are more and more IoT devices which
don't equip the physical touchpad nowadays. And for some reasons, their
Chassis type matches the condition of the touchpad job, this causes those
touchpad jobs will be executed but tester need to skip them manually.
Therefore, the manifest of touchpad will bring a huge benefit for us to
filter jobs out in advanced.
I add the has_touchpad manifest option and apply it to all of the
touchpad jobs. At the meanwhile, I remove the dmi.product requirement.
Ask tester about available graphics ports and adapters instead of relying on resource job (#282)
* Add manifest entries for graphics ports
* Split USB-C manifest entry
Some devices under test (DUT) have one or more USB Type-C connectors.
Some of these connectors offer direct HDMI/DisplayPort outputs if user
has an appropriate cables, while for others, a USB Type-C to
HDMI/DisplayPort adapter can be used to connect the DUT to an external
monitor.
For these cases, a new manifest (`has_usbc_video`) is created.
The old one, `has_usb_type_c`, is renamed `has_usbc_data` as it's used
for all tests related to data, be it USB drives, Ethernet adapters or
HID (keyboard, etc.).
* Update jobs requiring `has_usbc_data` manifest
* Use graphics ports manifest entries to decide whether jobs should be run
Instead of relying on the display resource job (that relies on
xrandr/gnome-randr to determine heuristically support for different
connectors), use manifest entries to determine if the monitor and audio
jobs should be run at all. Since manifest entries are decided manually
at the beginning of a test session, it will be more accurate.
Some very old jobs (monitor/{index}_svideo_{product_slug} and
monitor/{index}_rca_{product_slug}) that are not used in our current
test plans are kept, but the requirement on the display resource job is
removed so the display resource job can be removed entirely.
In addition, now that there is a dedicated manifest to handle video
output through the USB Type-C connector, a lot of jobs are updated to use
it instead of the older `has_usb_type_c`.
Fix #56
* Remove display resource job
This job was not reliable since it was based on heuristics that often
failed, especially on 22.04.
Replaced by manual manifest entries that are more accurate.
