ReleaseEngineering/TryChooser

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

Syntax Builder

To simplify using the TryChooser, you can use the TryChooser Syntax Builder website or the mercurial extension (which also functions as a command-line application, but is not maintained by RelEng).

Usage

try: OPTIONS

Options:

  -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 platform(s) you'd like to build for with a
      comma-separated list:
        linux,linux64,macosx,macosx64,win32,maemo5-qt,android-r7,maemo5-gtk
      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,mozmill-all
      or specify 'none' or 'all'.

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

  Email notification control (these are optional, default is to get emails on non-success) 

  -e --all-emails (optional)
      Get notified by email of each builder in the try run's results

  -n --no-emails (optional)
      Get no email notifications of each builder's results

  Bugzilla commenting

  --post-to-bugzilla Bug BUGNUMBER (optional)
      Get a comment in your specified BUGNUMBER at the end of the try run with a tally of the results and a tbpl link

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:

try: --build do
     --platform all
     --unittests all
     --talos none

Examples

try: -b do -p all -u all -t all

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

try: -b do -u crashtest

Debug and optimized builds, all available platforms, only crashtests, no talos:

try: -b d -p linux -u none

Linux debug build, no unittests, no talos:

try: -b do -u all -t chrome,nochrome

Debug and optimized builds for all platforms, all unittests, select talos:

try: -b o -u jsreftest,crashtest,mochitest-1 -t tp4,scroll

Opt builds on all available platforms, select unittests, select talos

You may follow the try: section with other text, but be careful to separate the sections with whitespace. That is, do

-t chrome,tp4 Some other stuff

instead of

-t chrome,tp4. Some other stuff

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: -b d -p all"
$ hg push -f ssh://hg.mozilla.org/try

With MQ

If you're using Mercurial Queues, you can use TryChooser by adding an empty patch with a "try:" string to the top of your queue:

hg qgoto your-patch
hg qnew -m "try: <Insert options here>" try
hg push -f -rtip ssh://hg.mozilla.org/try

After pushing, you can remove the empty patch:

hg qpop
hg qremove try

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 an error message on attempts to push to try as per bug 649402 where try syntax use was made mandatory.

What if make a syntax error in my commit message?

If you pass an invalid parameter, TryChooser will ignore it and substitute the default 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?

Try should have the same test/talos suites available to it as mozilla-central does so you can refer to tbpl for complete listings.

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?

Check out Self Serve!. With Self-Serve you can cancel pending builds, re-build/run completed builds/test/talos runs.

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.

Where are my macosx opt builds?

Since mac universal builds changed we now do the opt mac builds soley on macosx64 builders. The unittests for both 10.5 and 10.6 are then run on that build. This means, in order to get opt macosx reftest results you would need to do:

try: -b o -p macosx64 -u reftest

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).