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 when it completes. These are viewable in the Task Inspector.
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, eventually landing 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.