# Integrating Try Extender with Treeherder to Trigger Runnable Jobs

DevFeed: [Integrating Try Extender with Treeherder to Trigger Runnable Jobs](<https://devfeed.tech/articles/how-i-made-treeherder-do-something-it-was-not-meant-to-20253.md>)

Original publisher: [Read original article](<http://explique.me/TH/>)

Author: Explique-me

Published: 2015-12-05T00:00:00Z

Content type: article

Language: en

Sources: [Mozilla Automation](<https://devfeed.tech/sources/mozilla-automation.md>)

Topics: [API](<https://devfeed.tech/topics/api.md>), [Database](<https://devfeed.tech/topics/database.md>), [JSON](<https://devfeed.tech/topics/json.md>), [ui](<https://devfeed.tech/topics/ui.md>), [User experience (UX)](<https://devfeed.tech/topics/ux.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [database](<https://devfeed.tech/tags/database.md>), [jobs](<https://devfeed.tech/tags/jobs.md>), [json](<https://devfeed.tech/tags/json.md>), [ui](<https://devfeed.tech/tags/ui.md>), [ux](<https://devfeed.tech/tags/ux.md>)

## AI overview

The article describes integrating Try Extender with Treeherder to let users select and trigger runnable jobs. It explains the API, database, UI, and Pulse Actions changes used to expose possible jobs and schedule them, and notes usability and request-status limitations.

## Source excerpt

For the past couple of months I have been working on integrating Try Extender with Treeherder. The goal was to add an "Add new jobs" button to Treeherder that would display every possible job for that push. Users would then be able to click on the jobs they want to trigger them. It was a fun project in which I had a lot of help from the Treeherder team and I ended up learning a little about how TH works. How Treeherder shows jobs For every push, Treeherder makes a request to its API to obtain a JSON object with every job for that push and their respective symbols, status, types, platforms and whatever else is needed to correctly display them. Every single one of these jobs has an id and it's in a row in Treeherder's job database. Buildbot jobs enter TH's job database as part of the ETL layer. Celery tasks parse JSON files that are generated every minute by BuildAPI. Runnable jobs database Treeherder already knows how to get a list of jobs from an API endpoint and display them in the right places (if you are curious, mapResultSetJobs carries most of the weight). All I needed to do was add a new API endpoint with the list of every possible job (and the associated information). To feed the information to the new endpoint, I created a table of runnable jobs. Jobs enter this new table through a daily task that downloads and processes allthethings.json. Setting things up With the database part ready, some things had to be done on the UI side. An (extremely reasonable) assumption made by Treeherder is that it will only show jobs that exist. Since runnable jobs don't exist, I had to create a new type of job button that would not open the information panel and that would allow users to click on several jobs at the same time. The triggering part was done by sending Pulse messages to Pulse Actions, which would then schedule jobs using mozci and releng's amazing BuildBot Bridge (armenzg did a great job adding BBB support to mozci). Possible improvements The UX is not very intui