I'm going to convert bug 1632946 into a meta bug since there's various pieces that will get us there.

This bug focuses on porting the JS code that was written in order to support &test_paths in the job-view.

In short, we need to port some JS code from Push.jsx and the test Push_test.jsx.

We want an API that returns the data structure we need.
Don't worry about deprecating the JS code. I will take care of that.

The returning structure looks like this (see full structure in test):

{
      'test-linux1804-64/debug-mochitest-devtools-chrome-e10s-1': [
        'devtools/client/framework/browser-toolbox/test/browser_browser_toolbox.js',
        'devtools/client/framework/browser-toolbox/test/browser_browser_toolbox_rtl.js',
        'devtools/client/framework/browser-toolbox/test/browser.ini',
      ],
}

In order to create such structure we need to artifacts that are produced by the Gecko decision task:

• tests-by-manifest.json.gz
• manifests-by-task.json.gz

The code does the following:

• Fetch the two artifacts (code)
  • There's some decompression that happens
• Merge the two artifacts (code)

There's more code in there to support the job filtering in the UI, however, this is all you need to move into the backend to generate the structure you need and to support me switching to it later on.

The API should take as parameters the repo and the revision.

Optionally (we can file as follow up bugs):

• if you could cache the returning structure for 24 hours it would be great

At the moment, there will be many pushes that generate the exact same structure. If we have a method to convert into a sha we could cache the same object for many pushes. The reason that many pushes generate the same structure is because those two artifacts don't change often (We require additions/deletions of tests and manifests for them to change). In the future, these artifacts will change from push to push depending on what the bugbug schedules services says. To account for this, I will be storing a representation of test/manifests in our DB when the artifacts become available. Once I ingest that information (probably 2-3 weeks) I will be adjusting whatever code you land in here to use the newly stored information.

This does not block bug 1632946, however, it will help with bug 1626623.

Handing this over to Armen. Armen and I talked over Zoom and I think the approach I was using to merge the two artifacts on the server, then send the whole dict down to the UI is untenable. It's just too much data.

We talked about another approach where perhaps, when the user wants to filter on a test path, the UI will call the backend API with the test path strings. The back-end will figure out which tasks match those parameters and send back a list of task ids. Then the UI will use those ids to filter which jobs are shown.