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 Options
    1. 5.1 Is the CQ broken?
    2. 5.2 The CQ seems hung
    3. 5.3 Please Help! I just want to ask on irc !
    4. 5.4 My patch failed to apply
    5. 5.5 What about LKGR?
    6. 5.6 Where is the dashboard?
    7. 5.7 What's my position on the queue?
    8. 5.8 Sending a TBR patch fast
    9. 5.9 Skipping the Presubmit check, Try Jobs or Tree Checks
    10. 5.10 Sending CL through CQ in dry-run mode
    11. 5.11 Picking custom trybots
    12. 5.12 Try job results aren't showing up consistently on Rietveld
    13. 5.13 Binary files?
    14. 5.14 My CL has a bazillion files, will it blend?
    15. 5.15 Moving, renaming or copying files
    16. 5.16 Are CQ users required to be around when the patch is landed?
    17. 5.17 What determines the set of tests and targets the try bots run?
See also: Chromium OS Commit Queue.

What (is it)?

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:
...but not GYP, for instance.

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.
      • Only the issue owner, someone at @chromium.org or @google.com can check the box.
      • Yes, non-Chromium committers are allowed to use the commit queue but cannot LGTM a change.
    2. At the command line, type git cl set_commit
    3. Have a reviewer use 'Quick LGTM & CQ'.
  3. Wait 2~3 hours. The current list of patches to be queued can be found at Commit Queue Patches, while CQ progress can be tracked at Commit Queue Progress. The commit queue will wait automatically for the tree to reopen.
  4. Wait for an email from commit-bot@chromium.org with success or failure.

Why (is it broken)?

Please follow these general guidelines:
  1. Please report issues to chrome-troopers@google.com .
    In particular, if a try job result fails for a reason unrelated to your CL, please email troopers with a link to the failed build: click on the red bubble and copy that URL; for extra credit copy-paste the failing step. For manually run try jobs you can just forward the failure mail, while for CQ failures you need to do it yourself at present.
  2. If you have a feature request, feel free to file a bug, use label Build-CommitQueue. Be sure to search for current feature requests first.
  3. If you feel the try server is too slow, start with http://crbug.com/109763. Be sure to assign the bug to yourself first.

Options

COMMIT=false
If you want to test your CL through commit queue but are not ready to commit the changes yet, you can add this 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.

TBR=<username> 
This stands for "to be reviewed". If a change has a TBR line with a valid reviewer, the CQ will skip checks for LGTMs. Use with caution.

NOPRESUBMIT=true
If you want to skip the presubmit check you can add this line and the commit queue won't run the presubmit for your change.

NOTRY=true
If you can't wait for the try job you can add this line 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.

NOTREECHECKS=true
If you want to skip the tree status checks, so the CQ will commit a CL even if the tree is closed, add this 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).

CQ_INCLUDE_TRYBOTS=<trybots>
This flag allows you to specify some additional bots to run for this CL, in addition to the default bots. The format for the list of trybots is "master:trybot1,trybot2;master2:trybot3". This feature only works for recipe based bots right now.

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 commit-bot@chromium.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 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 8 minutes, so a maximum rate of 30 commits per hour.

Please Help! I just want to ask on irc !

Please report issues to chrome-troopers@google.com .

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

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

Skipping the Presubmit check, Try Jobs or Tree Checks

See the NOPRESUBMIT, NOTRY, and NOTREECHECKS options, above. Together these provide overrides that don't go quite as far as directly committing code (git cl land).

Sending CL through CQ in dry-run mode

See the COMMIT=false option, above.

Picking custom trybots

See the CQ_INCLUDE_TRYBOTS option, above.

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, binary file are supported by try jobs as well as CQ now! Except for PNG files: bug 339068.
This used to be a bigger problem in the past, but was fixed in bug 23608.

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.

What determines the set of tests and targets the try bots run?

This is controlled by a config file (chromium_trybot.json for most trybots). Also see this document for details on the analyze step.