- Did it fail at the Update step?
- Did your patch contain CRLF files? You can look at the 'patch' link in the 'update' step.
- Too bad for you. Create a separate commit to fix the file in the tree and try again with --revision 123
- Did you get GYP failures in the update 'stdio'?
- Maybe you screwed the GYP file.
- Did you get "HUNK", "fuzzing" or "offset" messages in the update 'stdio'?
- The files you are modifying have been modified on the tree. Maybe LKGR is more recent or older than your checkout. You can look at the build link in the email in the Build Properties section, search for the number beside revision. Maybe try specifying --revision on your try.
- Did it fail at the Compile step?
- Maybe your code is broken?
- Yes, that is a possibility. Sorry 'bout that.
- Maybe someone else broke the slave?
- That happens. Especially on Windows. Please try again and alert me with the build status url. You can use the --bot win flag to not try needlessly on other platforms.
- Maybe a clobber is required. There are command-line options to request clobber (most likely just -c).
- Did it fail an unrelated test?
- Maybe it was broken at that revision on the main waterfall. Please look up the revision and take a look on the main waterfall.
- Maybe the tree slave is broken?
- That happens. Please try again and alert me with the build status url.
- I get no email!
- Did you get a warning message when sending your job? By default, it sends it to your checkout credential.
- 'gcl try' fails
- Send an email to <tryserver at chromium dot 0rg>.
- The try server is soo slow
- When a clobber is needed, a full rebuild takes time.
- Maybe someone changed a GYP and forgot to update the svn:ignore?
- If you feel like getting a peer bonus, please fix the property accordingly, otherwise ping <tryserver at chromium dot 0rg>.
- The try server needs a clobber
- That happens, usually ask to someone knowledgeable on irc to fix it for you or ping maruel if no answer.
- You can also request a clobber using command-line flags (usually -c).
- error message: 'hostname nor servname provided, or not known'
- If you're using the try server from outside of Google, it will fail to look up the hostname and should then fall back to using svn to enqueue the try job. If svn fails, unfortunately, you'll only see the error message about the hostname, so you won't realize that svn is the problem.
- To fix, try this first: svn ls svn://svn.chromium.org/chrome-try
- If that last step didn't work, maybe you're using git try on Windows? In that case, you may have a mismatch where the tools are using a mix of depot_tools svn and cygwin svn. In that case, also type /usr/bin/svn ls svn://svn.chromium.org/chrome-try
- Anything else?
- Please update this guide.
Requesting new bots
File a bug to get a bot request going. Do this as early as possible and provide as many details as you can.
I'm modifying a DEPS, will it work?
I'm modifying a GYP file, will it work?
I'm modifying gyp scripts under src/tools/gyp, will it work?
Yes, but you have to use
--no_search, otherwise patch will fail saying it cannot find files to patch.
Get detailed command-line help
Use: git try -h (git will redirect --help to man which fails for git-try)
Or: trychange.py --help
Disable automatic try on gcl upload
To do this for 'gcl try': create a file at '~/.gcl_upload_no_try'
For 'git try' : Edit src/codereview.settings thusly: "TRY_ON_UPLOAD: False"
I have an awesome patch for depot_tools!
Use the same way to contribute code that for chromium in general, e.g.
How can I see what will happen before I submit the job?
--dry_run flag (which implies
--verbose) to (a) see what your patch is and (b) not actually submit the job when using git try or gcl try.
By default the trybot will patch your change against HEAD, so there might be differences in the files you are modifying between the revision you've been working on and HEAD. The easiest way to fix this is check which revision you were using, and then pass it to the try job with --revision, e.g., git cl try -rHEAD.
If this still doesn't work and:
- you are using git
- master is not upstream of the branch you are trying
then its possible there are uncommitted changes between your branch and master, causing the apply_issue to fail. In this case, use
git cl try
git try --upstream_branch=origin/master
Keep in mind that this means your branch cannot be committed until all upstream branches are committed first, even if the trybots succeed.
- Incremental build failure, slightly less probable but still happens occasionally. Try with
- The slave has a broken checkout and needs a complete checkout removal, rarely happens but still does. Reply to the try job email.
- Your patch is broken. Please don't completely rule this possibility out yet. :)
My patch includes updated webkit baselines (binary files) and it's not working
Correct! The try servers do not currently support binary patches.
I want to cancel my job, should I press the 'Stop' button?
No! DON'T EVER DO THAT. This button is for maintainers and is quite tricky to use correctly. Just let it go.
Why! you ask. You may stop it during the update step and leave the svn checkout locked, breaking the following tries. You may stop it during compilation, corrupting the PDB database, breaking the following jobs. You may stop it during ui_tests, leaving zombies around. You may stop it during unit_tests, leaving temp files around.
Run the try job only on one platform
--bot win or whatever 'builder' name you want to use from the waterfalls.
Run the try job for "real" Chrome OS
As of June 2014 the Chrome try server provides chromium.chromeos builders, which are 64-bit Linux builds of Chromium with OS_CHROMEOS=1. This means the CQ and try server will not compile or test 32-bit Intel or ARM Chrome OS builds. But you can try your changes on the Chrome OS side with cbuildbot. See How to patch in a Reitveld CL
in the Chromium OS remote trybot docs.