This repository has been archived by the owner. It is now read-only.
*DEPRECATED* Tools for integrating bugzilla and github workflows.
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Build Status Dependency Status devDependency Status


Autolander is a tool which manages continuous integration workflows between Bugzilla and Github. Autolander has several features including:

  • Automatic pull request to bugzilla attachment linking.
  • Integrates code for you once the bug has a R+ (from a suggested reviewer) and the autoland keyword.
  • The integration step includes several processes, but here is a quick summary:
    • Merges code to an integration branch.
    • The commits are ordered in the order that they are meant to be landed in master.
    • A taskgraph is submitted to taskcluster for each integration.
    • If a taskgraph fails, the commit is discarded, and newer commits are re-run on the integration branch.
    • On a successful taskgraph run, we fast-forward the base branch to the integration commit.
    • If we can not fast-forward the base branch, we re-create the integration branch from the base branch and replay all integrations on top of it.
  • Autolander will update the bug with the landing commit, and resolve the bug as fixed.


  • Pull request titles - a bug number is required in the pull request title.
  • Commit messages - Each commit message in the pull request must have a bug number.
  • TBD: If we should require a r= in each commit message (we may be able to include this info in the future from the bug automatically).

Basic Repository Integration

Autolander will check if you have either an autolander.json or a taskgraph.json in the project root in order to determine whether or not to run tests on treeherder. If you have neither of these then autolander will simply merge code to master when the autoland keyword is added.

Enabling Autolander for additional repositories

We don't yet have a UI in place to easily do this, so for the time being, Autolander needs a few things in place to function:

  • Add the Autolander user ( to your repository with permissions.
  • Add the heroku webhook to your repository, and make sure it receives events for pull requests:
  • Until the security team determines that it's safe to enable autolander across all components, the BUGZILLA_SUPPORTED_PRODUCTS configuration value needs to be updated to contain your bugzilla product. The whitelist is to ensure that the component suggested reviewers have been audited as any suggested reviewer will be able to land code into the repository once autolander is enabled. In production this config is currently stored in Heroku and you'll need someone with access to update this value.

Autolander Component Interaction

Autolander interacts between several components, some of which are:

  • Bugzilla - Attaches pull requests and comments on bugs.
  • Github - Listens for webhooks, and lands code.
  • Taskcluster - Publishes taskgraphs from integration branches before landing.
  • Treeherder - Updates treeherder UI with integration results.
  • Azure - Stores the list of bugs that we are interested in.
  • Pulse/AMQP - Receives updates for bugs and taskgraph updates.



Create configuration if needed. Copy the template config file to the environment (development or production), and fill in the keys. An example config/production.js file already exists which uses environment defines - this is useful for deploying to a server which already has these defined. Ask me if you need development keys.

cp config/development.js.tpl config/development.js

Running tests

End-to-end integration tests which test against real instances of bugzilla, pulse, github, taskcluster and treeherder. Running tests is the recommended way to develop for autolander.

# Run all tests for the project:
npm test

# Run a single test:
./test/ test/some_test.js

# Each test will automatically spin up the worker and web servers by default.
# It can be useful to run these on your own for debugging purposes.
# To do this, first spin up the web and worker instances.
DEBUG=* ./bin/web
DEBUG=* ./bin/worker

# Run tests with NO_SERVER=1 if you do this.
NO_SERVER=1 npm test

Local Environment

Ensure that the :autolander ( github account has push access to your repository.

Using ngrok for a tunnel to localhost is the easiest way to develop. Fork your repository of choice. Once you have a tunnel setup, add a webhook to your repository that points to

./ngrok 80

Start the server.

// You need to start both the web interface, and the listener.
node ./bin/web
node ./bin/worker

// Or start with debug logging:
DEBUG=* node --harmony ./bin/web
DEBUG=* node --harmony ./bin/worker

// Start for production and debugging
DEBUG=* node --harmony ./bin/web production
DEBUG=* node --harmony ./bin/worker production