Make use of perf framework context
Categories
(Tree Management :: Treeherder, defect, P3)
Tracking
(Not tracked)
People
(Reporter: igoldan, Unassigned)
Details
(Keywords: good-first-bug)
Currently, the Compare results against another revision hyperlink from Job Details associated to perf job (e.g.) points to a Compare view that's not entirely setup.
The view points to one of the correct revisions, but it doesn't point to the correct perf framework. It always defaults to talos, even if the original perf job was from raptor.
We need to address this small issue.
| Reporter | ||
Comment 1•6 years ago
|
||
Kimberly, would you like to work on this task?
Updated•6 years ago
|
Comment 3•6 years ago
|
||
Just returning from leave, and trying to get caught up where I left off on onboarding. Unassigning
Updated•6 years ago
|
Comment 4•6 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)
| Assignee | ||
Updated•4 years ago
|
Comment 6•4 months ago
|
||
Greg
Currently, the Compare results against another revision hyperlink from Job Details associated to perf job (e.g.) points to a Compare view that's not entirely setup.
Given that this bug could have been created before PerfCompare was created, do we need to get this to point to PerfCompare ?
Comment 7•4 months ago
|
||
Thanks for the ping about this! Actually, we don't have this issue anymore. It works fine with perfcompare since we pass the framework name as an argument to it. This is an example of a link we generate for a browsertime task: https://perf.compare/?newRepo=mozilla-central&newRev=887fb4b92f0ce8fab484377f1715d972ead217cc&frameworkName=browsertime
Description
•