New backfill action

If you use Treeherder on repositories that are not Try, you might have used the backfill action. The backfill action takes a selected task and schedules it nine pushes back from the selected task. You can see the original work here and the follow up here.

The mda task on push 48a10a9249b0 has been backfilled

In the screenshot above you can see that the task mdaturned orange (implying that it failed). In the screenshot we can see that a Mozilla code sheriff has both retriggered the task four more times (you can see four more running tasks on the same push) and has backfilled the task on previous pushes. This is to determine if the regression was introduced on previous pushes or if the failure is due to an intermittent test failure.

Once you select a task and click on the hamburguer menu you can get to the backfill action

The difference with the old backfill action is threefold:

1. The backfilled tasks include -bk in their symbol and group and it includes the revision of the originating task that was backfilled
2. The backfilled tasks schedule the same set of manifests as the starting task
3. The backfill action schedules a support action called backfill-task

Modified symbol for backfilled tasks

The modified symbol and group name for backfilled tasks is to:

1. Show that it is a backfilled task (rather than schedule by normal scheduling) and that it can have a modified set of manifests (see next section)
2. Show from which task it was backfilled from (by including the revision)
3. Group backfilled tasks together to make it clear that they were not scheduled by normal means

I’ve also landed a change on Treeherder to handle this new naming and allow to filter out normal tasks plus backfilled tasks.

From this link you can filter out mda tasks plus mda backfilled tasks

Manifest-level backfilling

Point number two from the above list is what changes the most. Soon we will be landing a change on autoland that will schedule some test tasks with a dynamic set of manifests. This means that a task scheduled on push A will have a set of manifests (e.g. set X) and the same task on push B can have a different set of manifests (e.g. set Y).

The new backfill takes this into account by looking at the env variable MOZHARNESS_TEST_PATHS which contains the list of manifests and re-uses that value on backfilled tasks. This ensures that we’re scheduling the same set of manifests in every backfilled task.

Support actions

You can skip reading this section as this is more of an architectural change. This fixes the issue that backfilled tasks could not be re-run.

Backfilled tasks are now scheduled by a support action called backfill-task. If on Treeherder we filter by backfill tasks you can see both the initial backfillaction and the backfill-tasksupport action:

Two backfill actions were triggered on push 48a10a9249b0

The action backfill has scheduled nine backfill-task and those are in charge of scheduling the mda task on that push.

Thanks for reading. Please file a bug and CC me if you notice anything going wrong with it.