Specify multiple builders using the default tests:
or specify multiple different test steps:
or specify a --gtest_filter:
Specify different test steps to run :
Specify a --gtest_filter
Runs the default tests on 'win_rel' but only compile on 'win':
Compiles on both 'win_rel' and 'win' without running tests:
Runs base_unittests on win_rel but no other test:
Runs a single specific test from base_unittests on win_rel:
Runs base_unittests and in addition default tests on win_rel:
What are the "defaulttests", you ask? Easiest answer is just to run a try job and look what is skipped. You can also search for the non_default factory property.
We have linux_valgrind and linux_tsan slaves to run popular valgrind tests.
ui_tests are not executed on linux_valgrind trybot but you could execute selected tests manually:
Please note that you can run tests locally on Linux and Mac with your usual Debug built binaries, so you can save some time by running Valgrind locally on these platforms.
The url for the current LKGR is: http://chromium-status.appspot.com/lkgr.
The last known good revision is determined by the last revision that passes green at: http://chromium-status.appspot.com/revisions
The list of tests and builders that need to pass are listed at masters/master.chromium.lkgr/lkgr_finder.py
LKGR is by definition behind ToT because it needs to be built and tested, and most likely another commit occured before a revision was vetted for LKGR.
Please, before contacting maruel, please look at these items:
Yes, but you have to use
Use: git try -h (git will redirect --help to man which fails for git-try)
Or: trychange.py --help
To do this for 'gcl try':
Use the same way to contribute code that for chromium in general, e.g.
Add the pseudo test 'compile' as a test filer, e.g.
By default the trybot will patch your change against the LKGR, so there might be differences in the files you are modifying between the revision you've been working on and the LKGR. The easiest way to fix this is check which revision you were using, and then pass it to the try job with --revision.
For example, if your change depends on some other changes newer than LKGR, you may want to try the patch against HEAD, i.e., git cl try -rHEAD.
If this still doesn't work and:
Keep in mind that this means your branch cannot be committed until all upstream branches are committed first, even if the trybots succeed.
Correct! The try servers do not currently support binary patches, but this is being worked on. Star http://crbug.com/23608.
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.
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.
We highly recommend you to use git. See http://code.google.com/p/chromium/wiki/UsingWebKitGit.
Go in src/third_party/WebKit and use
Use Rietvield WebUI with the "Try more bots" link. Alternatively, you can use:
git cl patch -b new-branch-name Rietveld-issue-id
git cl issue Rietveld-issue-id
git cl try
Where new-branch-name and Rietveld-issue-id should be replaced accordingly (give it a new branch name and link it with the id for the non-committer's CL on Rietveld).
Sorry, only Googlers can do this for now. You can get more information at the internal link.
Under the builder's build results page, look for the step entitled archive_webkit_tests_results. A zip archive of the entire results directory is available the (zip) link under this step.