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.
See the section on contributing code at chromium.org for how to create a branch and make changes.
Once a change is completed and tested locally, upload it to [codereview]:
git cl upload
Before submitting the code, use Gerrit to have it reviewed like any standard Chrome OS CL. See contributing code for details.
The Chrome commit queue has a very large pool of builders that will apply individual changes to the master, build them, and test them.
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.
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:
target_os = "chromeos" that runs browser_tests and unit_tests for Chrome on Chrome OS.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.
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!
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.