ReleaseEngineering/TryChooser

TryChooser lets you select specific jobs you want to run on tryserver. You use TryChooser by putting a try: block in the commit message of the topmost changeset when you push to try.

Syntax Builder

This site will help you build the syntax line to get what you want. TryChooser Syntax Builder

Usage

try: OPTIONS

Options:
  -a --do-everything
      Run everything that we'd run if you pushed to mozilla-central: debug /
      opt builds, all tests, all talos.

  -b --build TYPE
      Choose what type of builds you'd like made:
        --build d   gives debug builds only
        --build o   gives optimized builds only
        --build do  gives both debug and optimized builds

  -p --platform LIST
      Choose which desktop platform(s) you'd like to build for with a
      comma-separated list:
        linux,linux64,macosx,macosx64,win32
      or specify 'none' or 'all'.

  -m --mobile LIST
      Choose which mobile platform(s) you'd like to build for with a
      comma-separated list:
        mobile-maemo5-qt,android,etc.
      or specify 'none' or 'all'.

  -u --unittests LIST
      Choose which unittests you'd like run:
        crashtest,reftest,mochitests
      or give a subset of tests:
        mochitest-{1,2,3,4,5,o},xpcshell,opengl,jsreftest
      or specify 'none' or 'all'.

  -t --talos LIST
      Choose which talos suites you'd like to run:
        tp4,tscroll,tspider,etc.
      or specify 'none' or 'all'.

Note that if you specify --do-everything TryChooser will ignore any other options you provide.

Defaults

If you don't specify an option or if you give an invalid value for an option, TryChooser will use its default for that option:

--build do
--platform all
--mobile all
--unittests all
--talos none

Examples

try: -a: Run what mozilla-central's automation does: all platforms, all tests, all talos:

try: -b do -u crashtest: Debug and optimized builds, all available desktop and mobile platforms, only crashtests, no talos:

try: -b d -p linux -u none: Linux debug build, all available mobile platforms, no unittests, no talos:

try: -b o -p none: Mobile-only optimized builds, all unit tests, no talos:

try: -b do -m none -u all -t chrome,nochrome: Debug and optimized builds for all desktop platforms, no mobile, all unittests, select talos:

try: -b o -u jsreftest,crashtest,mochitest-1 -t tp4,scroll: Opt builds on all available desktop and mobile platforms, select unittests, select talos

Workflow

Without MQ

If you're not using Mercurial Queues, you can use TryChooser by including a "try:" string in the message of the commit you push to try:

$ (edit your code)
$ hg commit -m "Bug XXXXXX - Change foo to bar.  try: --do-everything"
$ hg push -f ssh://hg.mozilla.org/try

With MQ

If you're using Mercurial Queues, you can use TryChooser by modifying the commit message of your topmost patch to include a "try:" string:

$ hg qgoto your-patch
$ hg qref -e
(text editor appears.  Include "try: --do-everything".)
$ hg push -f ssh://hg.mozilla.org

FAQ

What if I don't put "try:" in my commit message?

If you don't give a "try:" string in your commit message, you'll get the default set of builds and tests.

What if make a syntax error in my commit message?

If you pass an invalid parameter, TryChooser will ignore it and substitute the defailt in its place. For instance, if you specify try: -b f -u crashtest, you'll get both debug and optimized builds, since "f" is not a recognized argument. You'll only get crashtest run on those builds, however.

Where's the full list of unit tests and talos tests I can request?

List of test suites used by TryChooser is here.

To match up the Talos suite name to the tests it runs you can go here. (eg: 'chrome' runs ts:tdhtml:twinopen:tsspider)

If you need help building the syntax line you can also go to the TryChooser Syntax Builder page.

What do I do if I need to add or remove a job after I push?

File a bug with this link. It's helpful if you check the ftp dir first to see what builds have actually completed and uploaded (since that is what releng triggers your tests and talos from). Include the email-changeset identifier of your ftp dir (it's also included in the e-mails tryserver sends you); e.g. "Please trigger myname@gmail.com-6860bd333c84 linux crashtest, no talos".

Whoever is currently on buildduty will see the bug and submit your request.

Where are my builds/test/talos?

Sometimes TBPL is missing results (e.g. bug 590526), and sometimes it feels like it's been a while since you kicked the build off and you're getting antsy for results. Here are some things you can look into before pinging the person on buildduty:

Did the build compile successfully? If it didn't, you won't get unittests or talos results.
- Look for your directory in the builds FTP server and see what has been uploaded. (You can also find here the email-changeset string that you'll need if you end up pinging releng.)
Check Running and Pending to view your build's status. These pages lie less often than TBPL.

Parsing details

The parser for TryChooser is here.

The basic algorithm is:

The commit message is split on 'try:'.
Whatever follows after 'try:' is passed to try_parser as a string.
The string is processed into a list of args handed to parse_known_args (thus keeping anything that is not a recognized argument from causing errors).