The Thunderbird try server works in exactly the same way to the Firefox try server with a few minor differences. The automation is based on the same hardware and tools, so there should be few differences.
Thunderbird's Try server is often referred to as "try-comm-central", or "try-cc", but usually it's just known as Try. Use an upper-case T if it makes things clearer.
To use the try server, you'll need Level 1 Commit Access. You can learn more about Mozilla's commit access policies and start the process of signing up for an account here: Becoming a Mozilla Contributor.
You need to make sure your
~/.ssh/configis properly configured to use the correct SSH username for the Mozilla Mercurial repository.
Your SSH config file should have something like this:
Try server has a separate repository based upon comm-central. You'll need to add the address to your Mercurial configuration file at
default = https://hg.mozilla.org/comm-central
try = ssh://hg.mozilla.org/try-comm-central
Having gained level 1 access and configured Mercurial, you can push to Try. In general, it's just a matter of applying your patch(es) and running
hg push -r . tryif you're planning to manually trigger tasks from the Taskcluster web interface.
For pushes via the command line, we recommend using the
push-to-tryextensions in order to simplify the commands required to automatically trigger jobs and tasks on the try server.
An example of a command to trigger all mochitest jobs for an artifact build will look like this:
hg push-to-try -s ssh://hg.mozilla.org/try-comm-central -m "try: -b o -p all -u mochitest --artifact"
Pushing to try-comm-central will create builds using the most recent mozilla-central code, which may or may not be a good idea at the time. Generally it's okay, but there may be unresolved problems between the two repositories. If you strike a problem, ask in the #maildev Matrix chat room. You can also work with a specific mozilla-central revision, see "Testing mozilla-central patches" below.
You can (and should) control what testing tasks you want to run on your push. There are several methods to do so:
This is the easiest and most common way. A special code (known as Try syntax) is put in the commit message of the tip-most revision being pushed, for example
try: -b o -p linux64 -u allcreates only an "opt" build on 64-bit Linux, and runs all of the tests on that build.
Here is the Try syntax try-comm-central understands:
-bBuild type. Use
ofor an opt build (most common),
dfor a debug build, or
-pPlatform. There are five platforms. Each also has a
-shippablevariant, which is a complication you probably don't need to think about.
macosx64Mac OS (if you don't need a debug build, specify
allfor all platforms
-uUnit test suites.
For more control, a special file named
try_task_config.jsonand containing a list of the tasks to run is included in one of the pushed revisions.
The contents of the file look like this:
use-artifact-buildstells the Try server to do an artifact build. Set to false or remove it for a full build. See the Artifact Builds page for more information.
tasksis a list of tasks to run. In this example it's all of the 64-bit Linux tests. A 64-bit Linux build will also run, because it is required by the tasks specified.
A copy of the file with all available tests is maintained here. A typical workflow would be to copy the file into your working directory, remove the tasks you don't want to run, and commit it. For efficiency you could export the commit as a patch and import it again when needed.
Task configurations and names change over time. If you're not getting the tasks you requested, this may be why.
To find the name of any particular task, click on existing instance in Treeherder, then look for the "job name" in the lower-left corner of the page.
If you commit with neither Try syntax nor a
try_task_config.jsonfile (or you want to add to an existing run), you can one or more tasks using Treeherder. Once the decision (D) task has completed, click the drop-down arrow to the right of it, and choose "Add new jobs".
If you have changes that affect mozilla-central, you may wish to do a Try run to check Thunderbird isn't broken. Here's how:
- 1.In your mozilla-central directory, apply your patch. Then run
./mach try emptyto push to the mozilla-central Try repository. You'll need to know the revision number of your push, which will be in the message printed to the console.
- 2.Move to your comm-central directory.
- 3.Modify the file
GECKO_HEAD_REFto point to the revision you previously pushed to M-C's try with
mach try empty.
- 4.Now push to try-comm-central as per usual.
You can change
.gecko_rev.ymlto point to any revision on the mozilla-* trees to test your comm-central patch against them.
When doing a Try run for patches to
comm-esr##, the steps are the same as when doing a Try run for
comm-central. (For example, you do not need to change anything in your
hgrcfile.) The try server is smart enough to automatically detect which one to build and test. This works because of the
.gecko_rev.ymlfile. Note that some things might not work the same way as on
--artifactoption only works on