third_party/skia/site/dev/testing/skialab.md
Skia's buildbots are hosted in three places:
This page covers the local SkiaLab in Chapel Hill.
The SkiaLab consists of three wireframe racks which hold machines connected to two KVM switches. Each KVM switch has a monitor, mouse, and keyboard and is the primary mode of access to the lab machines. In general, the machines are on the same rack as the KVM switch used to access them. The switch nearest the door (labeled "DOOR"), is connected to machines on its own rack as well as a smaller rack closer to the door.
Each machine is labeled with its hostname and the number or letter used to access it on the KVM switch. Android devices are located on the rack nearest the interior of the office (the KVM switch is labeled "OFFICE"). They are labeled with their serial number and the name of the buildslave they are associated with. Each device connects to a host machine, either directly or by way of a powered USB hub.
Disclaimer: Please ONLY make changes on a lab machine as a last resort, as it is disruptive to the running bots and can leave the machines in a dirty state. If you must make changes, such as cloning a copy of Skia to run tests and debug failures, be sure to clean up after yourself. If a permanent change needs to be made on the machine (such as a driver update), please contact an infra team member.
Sometimes failures can only be reproduced on a particular hardware configuration. In these cases, it is sometimes necessary to log into the host machine where a failing bot is running in order to debug the failure.
From the Status page:
Follow the same process as above, with some slight changes:
On the Status page, click the box for the failed build.
Click the "Lookup" link for the host machine. Remember the name of the buildslave which ran the build.
The hosts page will display the information used to access the host machine for the device as well as the serial number for the device next to the name of its buildsave.
Walk over to the lab and find the Android device with the serial number from the hosts page. Hold the power and volume-up buttons until the device reboots.
Access the host machine for the device, per the above instructions. Use the
which_devices.py script to verify that the device has re-attached. From
the home directory:
$ python buildbot/scripts/which_devices.py
This assumes that we're just adding a host machine for a new buildbot slave, and doesn't cover how to make changes to the buildbot code to change the behavior of the builder itself.
killall python on Linux and Mac, and just close any cmd instances which
pop up on Windows.Locate or add a host machine. We generally want to keep the number of devices attached to each host below 5 or so. If a new host machine is required, follow the above instructions for bringing up a new buildbot host machine, with the exception that the slave corresponds to the Android device, not the host machine itself.
Ensure that the buildslave is not yet running:
$ killall python
Disable MTP and PTP on the device. Some devices require one or the other to be enabled; in that case, select PTP and choose to 'do nothing' when attaching to the host machine.
Connect the device to the host machine, either through a powered USB hub or directly to the machine.
Make sure that the device is in developer mode and that USB debugging is enabled.
Authorize the device for USB debugging on the host machine by checking the "always allow" box on dialog box which appears on the Android device after plugging it into the host.
Ensure that the device appears as "connected" when you run the
which_devices.py script:
$ python buildbot/scripts/which_devices.py
Reboot the machine to start the buildslave.
TODO(borenet): Migrate from Google Docs.
OS-specific instructions are available in a Google Doc
skiabot-<hardware type>-<OS>-<disk image revision #>