LogoLogo
  • About Thunderbird
  • Contributing to Thunderbird
    • Getting Started Contributing
    • Setting Up A Build Environment
    • Building Thunderbird
      • Windows Build Prerequisites
      • Linux Build Prerequisites
      • macOS Build Prerequisites
      • Artifact Builds
    • Codebase Overview
      • Account Configuration
      • Address Book
      • Chat Core
        • Notifications
        • Message Styles
        • Keyboard shortcuts
        • Chat Core Protocols
        • Contacts
      • Mail Front-End
    • Tutorials and Examples
      • Hello World Example
      • Thunderbird Live Development Videos
    • Fixing a Bug
      • Bug Triaging 101
        • Bug Status Classicification
        • Bug Types
        • Garbage Collection
        • Narrow the Scope
      • Using Mercurial Bookmarks
      • Using Mercurial Queues
      • Lint and Format Code
      • Using ESLint to Format Javascript Code
      • Try Server
      • Landing a Patch
      • Care and Feeding of the Tree
    • Testing
      • Running Tests
      • Adding Tests
      • Writing Mochitest Tests
  • Planning
    • Roadmap
    • Android Roadmap
    • Supported Standards
  • Add-on Development
    • Introduction
    • What's new?
      • Manifest Version 3
    • A "Hello World" Extension Tutorial
      • Using WebExtension APIs
      • Using a Background Page
      • Using Content Scripts
    • A Guide to Extensions
      • Supported Manifest Keys
      • Supported UI Elements
      • Supported WebExtension APIs
      • Thunderbird's WebExtension API Documentation
      • Thunderbird WebExtension Examples
      • Introducing Experiments
    • A Guide to Themes
    • Developer Community
    • Documentation & Resources
      • Tips and Tricks
    • Add-on Update Guides
      • Update for Thunderbird 128
      • Update for Thunderbird 115
        • Adapt to Changes in Thunderbird 103-115
      • Update for Thunderbird 102
        • Adapt to Changes in Thunderbird 92-102
      • Update for Thunderbird 91
        • Adapt to Changes in Thunderbird 79-91
      • Update for Thunderbird 78
        • Adapt to Changes in Thunderbird 69-78
      • Update for Thunderbird 68
        • Adapt to Changes in Thunderbird 61-68
      • How to convert legacy extensions?
        • Convert wrapped WebExtensions to modern WebExtensions
        • Convert legacy WebExtensions to modern WebExtensions
        • Convert legacy overlay extension to legacy WebExtension
        • Convert legacy bootstrapped extension to legacy WebExtension
  • Releases
    • Thunderbird Channels
    • Release Cadence
    • Uplifting Fixes
    • Feature Flags
    • Tracking Fixes for Releases
    • Contributing to Release Notes
Powered by GitBook
On this page
  • Getting access to the Try Server
  • Configure your SSH Host
  • Adding Try to your Mercurial configuration
  • Pushing to Try
  • Choosing what tasks to run
  • Try syntax
  • Try task configuration
  • Adding tasks to an empty Try run
  • Get an installable build from a Try run
  • Testing mozilla-central patches
  • Testing comm-beta and comm-esr patches

Was this helpful?

Edit on GitHub
Export as PDF
  1. Contributing to Thunderbird
  2. Fixing a Bug

Try Server

PreviousUsing ESLint to Format Javascript CodeNextLanding a Patch

Last updated 13 days ago

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.

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.

Getting access to the Try Server

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

Configure your SSH Host

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:

Host hg.mozilla.org
  User nemo@thunderbird.net

Your User should match the SSH username that has been grante .

Adding Try to your Mercurial configuration

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

Pushing to Try

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:

hg push-to-try -s ssh://hg.mozilla.org/try-comm-central -m "try: -b o -p all -u mochitest --artifact"

Choosing what tasks to run

You can (and should) control what testing tasks you want to run on your push. There are several methods to do so:

Try syntax

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

    • marionette

    • all

Try task configuration

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:

{
  "version": 1,
  "use-artifact-builds": true,
  "tasks": [
    "test-linux1804-64-qr/opt-mochitest-thunderbird-e10s-1",
    "test-linux1804-64-qr/opt-mochitest-thunderbird-e10s-2",
    "test-linux1804-64-qr/opt-mochitest-thunderbird-e10s-3",
    "test-linux1804-64-qr/opt-mochitest-thunderbird-e10s-4",
    "test-linux1804-64-qr/opt-mochitest-thunderbird-e10s-5",
    "test-linux1804-64-qr/opt-mochitest-thunderbird-e10s-6",
    "test-linux1804-64-qr/opt-mochitest-thunderbird-e10s-7",
    "test-linux1804-64-qr/opt-xpcshell-e10s-1",
    "test-linux1804-64-qr/opt-xpcshell-e10s-2",
    "test-linux1804-64-qr/opt-xpcshell-e10s-3",
    "test-linux1804-64-qr/opt-xpcshell-e10s-4"
  ]
}

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.

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.

Adding tasks to an empty Try run

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

Get an installable build from a Try run

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.

Testing mozilla-central patches

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

  2. Move to your comm-central directory.

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

It's not required, but you should base your comm-central patch on a known good revision of comm-central (probably the tip), and your mozilla-central patch on the matching mozilla-central revision (also probably the tip). Otherwise changes made to one tree but not the other (such as build configuration changes) can cause problems.

To find the matching revision, open the log of the comm-central decision (D) task and search for "built from mozilla-central revision".

Testing comm-beta and comm-esr patches

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.

Firefox try server
Level 1 Commit Access
Becoming a Mozilla Contributor
Level 1 Commit Access
access the repository via HTTP
#maildev Matrix chat room
Artifact Builds page
Artifact Builds page
here
https://hg.mozilla.org/try
try syntax commands