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.
{% hint style="info" %} 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. {% endhint %}
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
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
:
[paths]
default = https://hg.mozilla.org/comm-central
try = ssh://hg.mozilla.org/try-comm-central
You can of course access the repository via HTTP, but not push to it, hence the ssh:// address.
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 try
.
{% hint style="warning" %} 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 on the #maildev IRC channel.
You can also work with a specific mozilla-central revision, see "Testing mozilla-central patches" below. {% endhint %}
You can (and should) control what testing jobs you want to run on your push. This is usually done by using special code (Try syntax) 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.
This is the Try syntax try-comm-central understands:
-b
Build type. Useo
for an opt build (most common),d
for a debug build, ordo
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 Linuxlinux64
64-bit Linuxmacosx64
Mac OS (if you don't need a debug build, specifymacox64-shippable
instead)win32
32-bit Windowswin64
64-bit Windowsall
for all platforms
-u
Unit test suites.marionette
andmarionette-headless
mochitest-thunderbird
mozmill
xpcshell
all
--artifact
Artifact builds. See the Artifact Builds page for more information.
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.
- Modify the file
.gecko_rev.yml
– changeGECKO_HEAD_REPOSITORY
tohttps://hg.mozilla.org/try
, andGECKO_HEAD_REF
to point to the revision you previously pushed to M-C's try withmach try empty
. - 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
).