Task graph

This article needs an editorial review. How you can help.

After a change to the Gecko source code is pushed to version-control, jobs for that change appear on Treeherder. How does this work?

  • A "decision task" is created to decide what to do with the push.
  • The decision task creates a lot of additional tasks. These tasks include build and test tasks, along with lots of other kinds of tasks to build docker images, build toolchains, perform analyses, check syntax, and so on.
  • These tasks are arranged in a "task graph", with some tasks (e.g., tests) depending on others (builds). Once its prerequisite tasks complete, a dependent task begins.
  • The result of each task is sent to TreeHerder where developers and sheriffs can track the status of the push.
  • The outputs from each task -- log files, Firefox installers, and so on -- appear attached to each task (viewable in the Task Inspector) when it completes.

All of this is controlled from within the Gecko source code, through a process called task-graph generation.  This means it's easy to add a new job or tweak the parameters of a job in a try push and eventually land that change on an integration branch.

The details of task-graph generation are documented in the source code itself, including a some quick recipes for common changes.

Document Tags and Contributors

Tags: 
 Contributors to this page: djmitche, teoli
 Last updated by: djmitche,