Open Bug 1602893 Opened 1 year ago Updated 9 days ago

Can't run visual metrics on retriggered browsertime tasks


(Testing :: Raptor, defect, P2)

Version 3


(Not tracked)


(Reporter: sparky, Unassigned)


(Depends on 1 open bug, Blocks 1 open bug)


(Whiteboard: [perf:workflow])

We currently have visual metrics running on browsertime but when we retrigger those browsertime tests, there are no new vismet tasks created for it, see here for a sample "add-new" task which retriggers a browsertime test, but doesn't add a new vismet task for it:

It came from this push:

:ahal, I've added you as a CC to this bug in case you have any thoughts/ideas about this issue. For context, the vismet tasks are currently created dynamically with this transform:

A run-visual-metrics attribute dictates which tasks should have one created for them:

This problem is worse than I originally thought. I can schedule multiple vismet tasks, but each of them only processed the results from the first btime task that was created for them. (We can't retrigger, and we can't schedule multiple runs). So for me to be able to analyze the vismet data, I would have to make one push per trial which is a bit much. Here's a task where I tried it with 50 retriggers:

We have a partial solution here (thanks to :aki for the help):

  1. Select a browsertime test task (not a vismet task) that you want to retrigger.
  2. In the pop-up menu, select the ... and click on Custom Action.
  3. Pick the retrigger action if it wasn't already selected.
  4. Set downstream to true.
  5. Enter the number of times it should be retriggered in times.
  6. Retrigger!

This is the only method we have to retrigger these tasks. The --rebuild doesn't work but it would be cool if we could eventually get that to work with these tasks. Also note that the drop-down arrow on the push that provides the Custom Push Action option doesn't work for this either.

I've added that information to the wiki as well:

I don't know if this workflow works anymore because you can't do retriggers on jobs that succeed.

Last I checked (last week), it still works for the browsertime tests. Are you referring to raptor-browsertime or mozperftest?

Using ./mach try fuzzy --retry N and getting stale data is a big footgun still.

Whiteboard: [perf:workflow]
Depends on: 1677559
You need to log in before you can comment on or make changes to this bug.