This page describes the Gerrit Commit Queue for Chromium OS (also known by the code name "Paladin")
The goal of the Commit Queue is to vet changes (build and test them on multiple platforms) and push them on behalf of developers. It is responsible for not only committing changes, but also doing the Portage voodoo (uprevving ebuilds) necessary for other developers to see each others changes.
If your change has been reviewed and marked as "Looks good to me, approved", you can submit your change by selecting the review button and marking your change as both "Verified" and "Ready".
We first launch trybots to sanity check your change. This step is called PreCQ (Pre-Commit Queue). The trybots will compile your change, build images, and run unit and VM (virtual machine) tests on major platforms or platforms configured for the corresponding repositories/directories . This check only includes your change and related changes, and takes about 40 minutes.
The commit queue runs approximately once an hour, and picks up all changes that have been fully verified by PreCQ. It builds a full image (on a set of representative platforms) and runs tests on both virtual machines and real hardware. Each commit queue run takes approximately an hour.
The Commit Queue only picks up changes that have been approved, verified and marked ready, and only if all their dependencies are similarly approved, verified, and marked ready (see the "How do I specify the dependencies of a change?" section below).
If your change was picked up by the Commit Queue when the tree was throttled and the run failed, the Commit Queue would attempt to progress by selecting a smaller set of changes in the next run. As the results, your CL may be skipped for the subsequent run. The Commit Queue will continue reducing the number of CLs until a run completes successfully. You do not need to do anything because the Commit Queue will pick up your change for sure once the tree is open or it completes a successful run. If you still suspect there was some wrongdoing of the Commit Queue, please contact the build deputy to triage the issue.
The trybot ready flag lets committers kick off trybots before your change is approved. Select the "Trybot Ready" flag in Gerrit and it'll kick off a trybot. The status will be reported back to Gerrit. If you later mark the same patch as "Commit Ready", the trybot will already be complete, so your CL may be committed up to an hour faster.
You don't have to use the Trybot Ready flag -- if you don't, the CQ will kick off trybots anyway when your CL is approved.
Yes. This means that the Commit Queue will not try a change that depends on another until both it and the change it depends on are marked as ready for commit.
If you commit a stack of CLs to a branch locally, and upload them all together, Gerrit will already know about your dependencies and the commit queue will honor these dependencies.
If you want to specify a dependency on other CLs, you can specify a dependency on any CL in Gerrit by using CQ-DEPEND. Here's how it works:
Here's an example:
If you want to test your change with non-PreCQ configs, see the remote trybot documentation.
All projects under chromiumos/* and chromeos/* in gerrit and gerrit-int respectively are managed by the commit queue.
There are three places where the commit queue can fail to commit your change.
If you need more information about a build failure, you can look at the commit-queue builders on the internal and external waterfalls and find the build run which has your CL in the CommitQueueSync stage. These are the same logs other builders would have so delve accordingly. The Commit Queue also sends a snippet of the build log and a link to help you debug the issue.
No. However, it will commit any CLs it is processing if the tree is Throttled.
e.g. Tree is open, CQ picks up your CL, tree goes to throttled, CQ finishes testing & merges your CL.
Please do not bypass the commit queue unless it is necessary. That said, to bypass the commit queue, hit the submit patch button and select "Yes, I'm a chump".
If the Commit Queue finds that there are no changes that have been verified by trybots, the commit queue will start picking up unverified changes. This should only happen either at off-hours (when few developers are submitting changes) or when the trybot waterfall is having issues.
If the Commit Queue is down or consistently broken, please close the tree and contact a Build Sheriff or trooper immediately (chrome-troopers [at] google.com).