1602763 - Add a way to filter by a specific commit next to the "fixed by commit" field while filtering jobs in Treeherder

Status: NEW

(Tree Management :: Treeherder: Frontend, enhancement, P3)

Description

[Alexandru Michis [:malexandru]]

Attachment: Fix_by_commit.PNG

Whenever a backout is made, failures that appear on Treeherder and are caused by the regressing changeset are classified as "fixed by commit" along with the backout changeset.

I think it would be useful to be able to filter jobs on treeherder by a specific changeset after choosing "failure classification" -> "fixed by commit" in the "Filter by a job field" query.

This would enable developers to easily see which regressions were caused by their pushes, as well as making the history of these regressions easier to see further down the line along the many pushes and jobs that appear on treeherder.

Also, I don't exactly know the inner workings of how data gets moved around, but this could enable an easier tracking of regressions, or perhaps the collection of some other useful data and/or statistics.

Comment 1

[Alexandru Michis [:malexandru]]

Cameron, would this be possible with the current way that TH caches its information?

Comment 2

[Cameron Dawson [:camd]]

If I understand you correctly, are you asking to be able to see all the jobs that are classified as Fixed By Commit and specify the commit they were fixed by? If I have that right, then yes, this would be possible. I'm not quite certain how to surface that in the UI yet. Probably just adding a field you can filter by called commit fixed by or something to that effect.

We store the classification in a table called notes and there is a text field which holds the commit SHA in the case of a FBC. The thing is that we don't normally download the notes for all the jobs. Only for the selected one. (We try to minimize the amount of data, since it's a lot). But we could do that. And then filtering would be straight forward.

So, yes, it's definitely possible to do! :)

I will add this to our backlog. But, to set expectations, we are a very small team, so I'm not sure when this will bubble up to the surface. Would you want to take a crack at it? :)

Comment 3

[Alexandru Michis [:malexandru]]

I would take a shot at it but sadly my knowledge in this domain (UI, frontend) is very limited since I work as a code sheriff.

It's not an urgent matter, so there is no hurry to implement this, just a good tool that would greatly improve the workflows of developers and of us sheriffs.