The Chromium Projects

Search this site

Except as otherwise noted, the content of this page is licensed under a Creative Commons Attribution 2.5 license, and examples are licensed under the BSD License.

Chromium Commit Queue

Contents

  1. 1 What (is it)?
  2. 2 Design document
  3. 3 How (does it work)?
    1. 3.1 Current process for the user
  4. 4 Why (is it broken)?
  5. 5 Want (to hack)?
  6. 6 FAQ
    1. 6.1 Is the CQ broken?
    2. 6.2 The CQ seems hung
    3. 6.3 Please Help! I just want to ask on irc !
    4. 6.4 My patch failed to apply
    5. 6.5 What about LKGR?
    6. 6.6 Where is the dashboard?
    7. 6.7 What's my position on the queue?
    8. 6.8 Sending a TBR patch fast
    9. 6.9 Skipping the Try Jobs
    10. 6.10 Try job results aren't showing up consistently on Rietveld
    11. 6.11 Binary files?
    12. 6.12 My CL has a bazillion files, will it blend?
    13. 6.13 Moving, renaming or copying files
    14. 6.14 Are CQ users required to be around when the patch is landed?

What (is it)?

It's a service (aka a bot) that commits rietveld changes for you. 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.

Design document

How (does it work)?

The commit queue is not really a queue at the moment, since it processes the changes out of order. This may be changed eventually. This means a CL can be committed before another CL that was triggered much later. This can happen when a try job is flaky.

Current process for the user

  1. Upload a review to rietveld where it gets reviewed and LGTM'ed.
  2. One of:
    1. Check (select) the 'Commit' checkbox on a Rietveld issue, on the particular patchset that has been approved. Checking the checkbox is the only action required and there will be no immediate feedback in the form of messages, etc, to notify you that something has happened.
      1. Only the issue owner, someone at @chromium.org or @google.com can check the box.
      2. Yes, non-Chromium committers are allowed to use the commit queue but cannot LGTM a change.
    2. Have a reviewer use 'Quick LGTM & CQ'.
  3. Wait 2~3 hours. The current list of patches to be queued can be found at https://codereview.chromium.org/search?closed=3&commit=2, while CQ progress can be tracked at https://chromium-status.appspot.com/cq/me. The commit queue will wait automatically for the tree to reopen.
  4. Wait for an email from [email protected] with success or failure.

Why (is it broken)?

Please follow these general guidelines:
  1. If a specific CL is ignored by the CQ; please file a bug at bit.ly/chromeinfraticket
  2. If the commit queue seems dead, please email chrome-troopers@.
  3. If you have a feature request, feel free to file a bug, use label Build-CommitQueue and assign it to iannucci@. Be sure to search for current feature requests first.
  4. If you feel the try server is too slow, start with http://crbug.com/109763. Be sure to assign the bug to yourself first.
  5. In general, just ask commit-bot@chromium directly instead of asking almost 3000 people on chromium-dev@. I monitor IM and email more than chromium-dev@ or IRC.

Want (to hack)?

Feeling adventurous (or generous)?
  1. Get the code:
    1. gclient config svn://svn.chromium.org/chrome/trunk/tools/commit-queue
    2. gclient sync
    3. You can browse the sources online.
  2. To update the chromium-status dashboard, you'll need the code of the AppEngine instance:
    1. git svn clone svn://svn.chromium.org/chrome -Ttrunk/tools/chromium-status chromium-status
    2. You can browse the sources online.
  3. Send the code review with git cl to iannucci@.

FAQ

Is the CQ broken?

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 [email protected].

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 svn.chromium.org, src.chromium.org, git.chromium.org, it's likely to be ignored by the Commit Queue. It usually happens for git users with a non-standard remote, fix your upstream branch and create a new issue.

The CQ seems hung

Is the tree open?
It commits 4 CLs every 10 minutes, so a maximum rate of 24 commits per hour.

Please Help! I just want to ask on irc !

Go for it, but unless it happens maruel@/iannucci@ are currently watching, nobody is going to be able to help you much. Contact [email protected].

My patch failed to apply

What about LKGR?

The Commit Queue has never known, used or cared about LKGR. It always uses HEAD, the tip of tree.

Where is the dashboard?

What's my position on the queue?

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:

Sending a TBR patch fast

You can't wait for review? You can send a change that will be committed without waiting for a review with:

git fetch origin
git checkout -b work_fast origin/master
# Quick, write your fix.
echo "A copy is available for 100000$USD upon request." >> LICENSE
git commit -a -m "Fix the license, show new opportunities

"
git cl upload --send-mail -c

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 TBR[email protected] in the CL description.
  • --send-mail sends an email right away.
  • -c sets the commit bit right away, sort for --use-commit-queue.
  • --cc [email protected],[email protected] to cc more people instead of putting everyone as reviewer.
Now, did you know there's git cl help upload?

Skipping the Try Jobs

If you can't wait for the try job you can add the following line to the CL description:

NOTRY=true

and the 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.

Try job results aren't showing up consistently on Rietveld

If you never had a HTTP 500 on GAE, chances are that you will.

Binary files?

Yes, still an issue, you can follow bug 23608. It has to do with some weird redirects Rietveld does.

My CL has a bazillion files, will it blend?

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.

Moving, renaming or copying files

Was implemented in bug 125984 and bug 125983. If the diff on Rietveld doesn't look right, use the --similarity (defaults to 50%) and disable/enable file copy with --find-copies/--no-find-copies. In case of confusing;

git cl help
man git diff

Are CQ users required to be around when the patch is landed?

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.