Life of a Chrome commit on Chrome OS

Warning: This document is old & has moved. Please update any links:

This document provides a brief overview of how Chrome changes get committed and tested on Chrome OS.

For details on non-Chrome Chrome OS changes, see Life of a Chrome OS commit.

Create a Chrome change

Make and upload changes

See the section on contributing code at for how to create a branch and make changes.

Once a change is completed and tested locally, upload it to [codereview]:

git cl upload

Have your change reviewed

Before submitting the code, use Gerrit to have it reviewed like any standard Chrome OS CL. See contributing code for details.

The Chrome commit pipeline

The Commit Queue and Tryservers

The Chrome commit queue has a very large pool of builders that will apply individual changes to the master, build them, and test them.

Before the patch is approved

A developer can click on ‘Choose trybots’ to select specific builders to run (there are a lot of them).

Alternately they can click ‘CQ dry run’ to run all of the builders that the CQ will run in advance, without scheduling a commit.

The commit queue

Once a change has been reviewed and approved, the developer can apply the CQ+2 label, which marks the change ready for the CQ.

Depending on what was changed, the CQ selects a suite of trybots for android, cros, linux/fuchsia, mac/ios, and win.

The cros trybots include:

  • linux-chromeos-rel: a linux builder with target_os = "chromeos" that runs browser_tests and unit_tests for Chrome on Chrome OS.
  • chromeos-amd64-generic-rel: a Simple Chrome builder that runs telemetry and dep:Chrome Tast tests in amd64-generic VMs.

If the CQ builders succeed then the change will be committed to the master. Otherwise the ‘CQ+2’ label will need to be reapplied once the failure is fixed or determined to be unrelated to the change.

The chromium waterfall

Once a change is committed on the master, it is picked up by the chromium waterfall. This includes a very large number of builders that will thoroughly test the commit, including a number of public Chrome OS builders and a few private builders. Their tests can run on linux-chromeos, Chrome OS VMs, and Chrome OS DUTs (Device Under Test).

Note: Due to lab limitations not every builder in the waterfall is included in the Commit Queue. For Chrome OS there are a few Debug and device testers that only exist on the waterfall. Failures there are infrequent but possible, so keep an eye out!

The Chrome OS commit pipeline for Chrome changes

Once a Chrome change lands in the master, it needs to be landed via PUpr uprev before it will be picked up by Chrome OS. PUpr watches chrome tags as they are created each day and cuts a CL to the current gardener to land. Changes are included in ChromeOS builds once the uprev CL makes it through the ChromeOS CQ. There is a PUpr Dashboard that shows the current status of the uprev CLs as well as the age of the current chrome version on ChromeOS.