See also: Chromium OS Commit Queue.
It's a service (aka a bot) that commits rietveld changes for you, instead of your directly committing the change. It is enabled for the following projects:
If you check the box for a project that is not handled, it will simply not be committed. So the "base url" must be set on your CL.
The design doc is in its own page and there's a design doc about the Try Server <-> Rietveld <-> Commit Queue 3-way integration.
Please follow these general guidelines:
Take a look at https://codereview.chromium.org/search?closed=3&commit=2&limit=100&order=modified. If there are issues older than ~4 hours, they could probably be stuck. Note that the Commit Queue could be stuck only for some issues but not all of them. In case of doubt, contact firstname.lastname@example.org.
If your CL hasn't been touched after a few minutes of checking the CQ bit, CHECK THE BASE URL ON YOUR ISSUE. If it's not something like
Is the tree open?
It commits 4 CLs every 8 minutes, so a maximum rate of 30 commits per hour.
Please report issues to email@example.com .
See the Try Server FAQ.
The Commit Queue has never known, used or cared about LKGR. It always uses HEAD, the tip of tree.
It's at https://chromium-status.appspot.com/cq. You can go to https://chromium-status.appspot.com/cq/me to see yours directly.
The CLs are processed out of order, so it's not because another is "before" yours that means it'll be committed before yours. You can see the load on the CQ by looking at the number of tests CLs pending:
You can't wait for review? You can send a change that will be committed without waiting for a review with:
echo "A copy is available for 100000$USD upon request." >> LICENSE
git commit -a -m "Fix the license, show new opportunities
This'll still check for try jobs; see the next section if you can't wait for them, either.
The important part is to have TBRfirstname.lastname@example.org in the CL description.
Now, did you know there's
If you can't wait for the try job you can add the following line to the CL description:
and the commit queue won't run the try job for your change and will just commit the CL as soon as the tree is open, assuming the presubmit check passes. Amazing. Be very careful with this option.
If you want to skip the tree status checks, so the CQ will commit a CL even if the tree is closed, you can add the following line to the CL description:
Obviously this is strongly discouraged, since the tree is closed for a reason. However, in rare cases this is acceptable, primarily to fix build breakages (i.e., your CL will help in reopening the tree).
Together these provide overrides that don't go quite as far as directly committing code (dcommit).
If you want to test your CL through commit queue but are not ready to commit the changes yet, you can add the following line to the CL description:
and the commit queue will schedule try jobs for your issue, but only close instead of commit the issue after it passes all tests.
You can select which trybots to run for your CL by adding one of the following lines to the CL description:
* CQ_TRYBOTS=<trybots>. This flag allows you to list every bot that you want to run for this CL.
* CQ_INCLUDE_TRYBOTS=<trybots>. This flag allows you to specify some additional bots to run for this CL, in addition to the default bots.
* CQ_EXCLUDE_TRYBOTS=<trybots>. This flag allows you to specify some bots to exclude from the default set of bots to run.
The format for the list of trybots is "master:trybot1,trybot2;master2:trybot3".
This feature only works for recipe based bots right now.
If you never had a HTTP 500 on GAE, chances are that you will.
Yes, binary file are supported by try jobs as well as CQ now!
This used to be a problem in the past, but was fixed in bug 23608.
The CQ was able to commit a CL with 838 files so it is technically possible; https://codereview.chromium.org/12261012/. The likelihood of the CQ failing increases exponentially with the number of files in the CL.
Was implemented in bug 125984 and bug 125983. If the diff on Rietveld doesn't look right, use the
In general, no, as the CQ can land at any time (including very long time), and any breaking patches can be kicked about by the sheriff. After all, that's the job of the sheriff. You will get an email when the CQ commits, so you can jump on your nearest laptop if necessary.
If you expect your patch to be hard to revert, is touching several files and directories or move files around, you may want to stay around in case there is an incremental build failure or something hard to diagnose.
Also, if you commit on the weekend, don't expect a build sheriff to back out your crap so keep an eye open when you receive the CQ commit email.