ReleaseEngineering/TryChooser: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Usage: -f)
Line 41: Line 41:


   -f --failure-emails (optional)
   -f --failure-emails (optional)
       Get no email notifications of each failed builder's results
       Get email notifications of each failed builder's results
</pre>
</pre>
<pre>
<pre>

Revision as of 03:20, 31 July 2012

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,android,android-xul,maemo5-gtk,maemo5-qt
       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 no emails)

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

   -f --failure-emails (optional)
       Get email notifications of each failed 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
try: -b o -u all -n --post-to-bugzilla bug 456234
Opt builds on all available platforms, all unittests, no emails, results posted to bug 456234

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

Note: If you are running Mercurial 2.1 or higher, see this note about phases. (bug 725362)

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 want PGO for my build

Until bug 691673 is resolved, you'll have to do a small hack if you want PGO to work on your try push. Since bug 558180 landed, mozconfig-extra* mozconfigs aren't sourced. You'll need to add "mk_add_options MOZ_PGO=1" to

  • browser/config/mozconfigs/linux32/nightly
  • browser/config/mozconfigs/linux64/nightly
  • browser/config/mozconfigs/win32/nightly

as desired. These builds will not report any differently.

If you don't have those files in your tree, you'll need to add "mk_add_options MOZ_PGO=1" to the mozconfig-extra-$platform file for Linux, Linux64 and Win32 (as desired)

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

The email preferences are parsed out in the try_mailer script, and the --post-to-bugzilla flag is currently a work in progress but will land in the RelEng tools repo as part of the Bugzilla Autolanding project.