When contributing code to Chromium, the last step in the life of a change list is committing it.
The preferred way of committing changes is via the commit queue.
However, in certain circumstances it is acceptable or necessary to directly commit your change, bypassing the commit queue. This is discouraged however, due to not running the tests (hence higher risk of breakage), and requires more supervision on the part of the committer.
If you just wish to skip tests, but otherwise use the CQ, you can use
NOTRY=true in the Rietveld issue description, though you should run tests manually if possible (locally and on try bots).
In a nutshell:
- Have the change reviewed per usual process contributing code, with an issue and description on Rietveld, and sufficient LGTMs or TBRs (since presubmit OWNERS approval test isn't run when dcommitting).
- Run tests manually, both locally and using the try server for other platforms, to reduce risk of breakage (since try jobs aren't run when dcommitting). Try jobs can be run individually via Rietveld, while the standard set can be run from the command line via
- Join the #chromium IRC channel, so that sheriffs can notify you of possible breakages.
- Check that the tree is open (green): Chromium Tree Status :: Blink Tree Status
- Double-check that the tree is open.
- Commit as per below, preferably using
- See if there are any immediate messages on IRC.
- Stay on IRC for an hour or so in case anything happen afterwards.
Good reasons to dcommit code:
Marginal reasons to dcommit code:
- You are reverting at previous change that broke the build.
- The change can't be processed by the commit queue (see Build-CommitQueue bugs), such as changing file permissions (Issue 162196).
- A presubmit script is failing.
- If the failure is a false positive, if at all possible, please fix the script instead.
- The change is very big (e.g., large-scale formatting changes or renaming), so by the time it's finished uploading to Rietveld the patch is out of date and won't apply when the CQ tries it.
- If at all possible, try breaking up the patch and landing normally. Even innocuous-looking changes can cause breakages.
Bad reasons to dcommit code:
- The commit queue is too slow (unless the slowness means the change is out of date by the time it is processed) – please be patient.
- You want to skip tests – please use
- The tree is closed but you want to commit it anyway – please wait for tree to reopen.
In case of emergencies, please remember to at least:
- Create a Rietveld issue for description and reference.
- List OWNERS in
TBR (assuming no time for review).
- Join IRC, explain what's happening, and make sure there are no immediate objections.
git cl will squash all your commits into a single one with the description you used when you uploaded your change.
Pushing your change
It is also possible to use
svn dcommit, but this does not integrate with Rietveld (e.g., it uses your local git commit log as the commit message) and is discouraged, generally being reserved for emergencies.
Look out for breakage or regressions
If the most recent set of changes to the repository breaks the build, we say the tree is red, or closed. You cannot check in your changes until it is green again.
More low-level, you can check the BuildBot waterfalls (Chromium | Chromium OS) to see that the columns are mostly green before checking in your changes. Otherwise, you will not know if your changes break the build or not.
Please be available via the chromium IRC channel
when landing changes so that sheriffs may notify you of possible breakages
Committing a patch for a non-committer
First check that the non-committer has signed the CLA/CCLA and are listed in the AUTHORS and CL Description.
- If you use git
git cl patch <code review issue number>
- This command will download the patch from the code review website, apply the patch, and set the issue number.
- If you work on chrome:
- git cl try # and wait for green bots
- git cl dcommit -c 'Joe Noncommiter <email@example.com>'
- If you work on chromeos:
git commit --amend -s --author="$AUTHOR_NAME <$AUTHOR_EMAIL>"
git cl push -c
- You're done!
- If you use subversion / gcl
- Really, try to use
git cl patch if possible.
- You need to apply the patch locally with
curl http://... | patch -p0
- Recreate a CL with
gcl change foo
.svn/gcl_info/changes/foo and change the first 0 for the code review number
gcl commit foo