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.

The Chromium OS designs and code are preliminary. Expect them to evolve.
For Developers‎ > ‎

Try Server usage

  • The try server is a standard buildbot plus a set of slaves, currently ubuntu, mac and Windows XP.
  • The try server can be used with gcl try and git-try.
  • Any committer can use the try server.
    • External contributors can ask a committer to try the job for them and have the result email directly into their inbox.
  • Binary files are not supported. Text files with CRLF will have issues too.
  • Try server waterfall: http://build.chromium.org/buildbot/try-server/waterfall
  • All tests are run in Debug Mode.
  • The following tests are run by the try servers: 
check_deps, ipc_tests, unit_tests, app_unittests, ui_tests, test_shell_tests, base_unittests, net_unittests, googleurl_unittests, media_unittests, printing_unittests, browser_tests

Work flow

  • The developer first request a job to be run either implicitly with gcl upload or explicitly with gcl try or git try.
  • The try server will schedule one job per platform that you can follow live on the waterfall.
  • The job revision will default to http://chromium-status.appspot.com/lkgr. This can be overridden with the tools. RTM!
  • On each job end
    • An email will be sent to the email specified in the job. It is usually specified implicitly.
    • The corresponding review on http://codereview.chromium.org/ will have its try job status updated live.
  • On gcl commit / git cl dcommit (TBA), a PRESUBMIT.py will enforce that the job succeeded.

Layout tests

There are dedicated try bots you can use to run layout tests, they are not in the default pool so you need to refer to them manually:

gcl try foo --bot layout_win,layout_mac,layout_linux --root src/third_party/WebKit/WebCore

LKGR

Last known good revision is determined by the last revision that satisfies runs green for most of the steps on this custom waterfall.
Don't trust me to update the doc, look at the source at master.chromium/master.cfg, search for good_revision_steps.

What determines a try job success

Since LKGR doesn't check for most of the tests run on the try slaves to bump the default revision, these tests are not taken in account to determine a job has succeeded. Only the following tests must be green:
  • check_deps, ipc_tests, unit_tests, app_unittests, base_unittests, net_unittests, media_unittests, printing_unittests
Don't trust me to update the doc, look at the source at master.tryserver/master.cfg, search for TryJobStatusUpdate.

How does that relate to LATEST?

It doesn't. The continuous build selection is determined by a different (stricter) algorithm that has a much higher latency. It requires the Chromium XP/Mac/Linux to have a full green run to save the run as continuous build.

Troubleshooting failed try jobs

Please, before contacting maruel, please look at these items:
  • 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 unneededly on other platforms.
  • 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!
    • Try setting the environment variable EMAIL_ADDRESS. Maybe it's actually set and not looking at the right inbox?
  • 'gcl try' fails
    • Contact me
  • 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 me.
  • 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.
  • Anything else?
    • Please update this guide.

FAQ

I'm modifying a DEPS, will it work?

Yes.

I'm modifying a GYP file, will it work?

Yes.

I want to disable automatic try on gcl upload

Directly hack gcl.py.

I have an awesome patch for depot_tools!

Use the same way to contribute code that for chromium in general, e.g. gcl or git-cl.

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.

I want to run the try job only on one platform

Use --bot win or whatever 'builder' name you want to use from the waterfall.

My patch is in WebKit, not in Chromium proper

First you'll need to create a changelist — use 'gcl changelist' as usual, but make sure your current directory is src/third_party/WebKit/. You'll also need to append the "--force" flag or gcl will think the repo is read-only and abort.

Then when you submit the try job, append "--root src/third_party".