Try Server
Last updated
Was this helpful?
Last updated
Was this helpful?
The Thunderbird try server works in exactly the same way to the with a few minor differences. The automation is based on the same hardware and tools, so there should be few differences.
To use the try server, you'll need . You can learn more about Mozilla's commit access policies and start the process of signing up for an account here: .
You need to make sure your ~/.ssh/config is properly configured to use the correct SSH username for the Mozilla Mercurial repository.
Your SSH config file should have something like this:
Your User should match the SSH username that has been grante .
Try server has a separate repository based upon comm-central. You'll need to add the address to your Mercurial configuration file at path/to/comm-central/.hg/hgrc:
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 . try if you're planning to manually trigger tasks from the Taskcluster web interface.
For pushes via the command line, we recommend using the push-to-try extensions 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:
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 all creates 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:
-b Build type. Use o for an opt build (most common), d for a debug build, or do for both.
-p Platform. There are five platforms. Each also has a -shippable variant, which is a complication you probably don't need to think about.
linux 32-bit Linux
linux64 64-bit Linux
macosx64 Mac OS (if you don't need a debug build, specify macosx64-shippable instead)
win32 32-bit Windows
win64 64-bit Windows
all for all platforms
-u Unit test suites.
mochitest-thunderbird
xpcshell
all
For more control, a special file named try_task_config.json and containing a list of the tasks to run is included in one of the pushed revisions.
The contents of the file look like this:
tasks is 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.
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.json file (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".
When the build at https://treeherder.mozilla.org/jobs?repo=try-comm-central is complete (normally takes 1-2 hours):
In the black header below click "Artifacts and Debugging Tools".
Install the downloaded file.
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:
In your mozilla-central directory, apply your patch. Then run ./mach try empty to 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.
Move to your comm-central directory.
Now push to try-comm-central as per usual.
You can change .gecko_rev.yml to 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-beta or 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 hgrc file.) The try server is smart enough to automatically detect which one to build and test. This works because of the .gecko_rev.yml file. Note that some things might not work the same way as on comm-central (e.g. the --artifact option only works on comm-central).
You can of course , but not push to it, hence the ssh:// address.
Read the full list of to write in your commit message.
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 . You can also work with a specific mozilla-central revision, see "Testing mozilla-central patches" below.
--artifact Artifact builds. See the for more information.
use-artifact-builds tells the Try server to do an artifact build. Set to false or remove it for a full build. See the for more information.
A copy of the file with all available tests is maintained . 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.
Click the green "B" (for binary) next to one of the following: "Windows 2012 x64 [shippable] opt", "Linux x64 [shippable] opt", "OS X Cross Compiled [shippable] opt" (unless instructed to use a debug build).
In the Artifacts section, to download the install file click on target.installer.exe (Windows), target.tar.bz2 (Linux), or target.dmg (Mac).
Modify the file .gecko_rev.yml – change GECKO_HEAD_REPOSITORY to , and GECKO_HEAD_REV to point to the revision you previously pushed to M-C's try with mach try empty.
