Use of platform field

[gsnedders]

As it is, we currently have a platform field we don't make much use of.

The status-quo means we now have three versions of Chrome as different products: Chrome, ChromeAndroid, ChomeIOS.

This wasn't the original intention of the schema, but it does seem to be how we're using it—probably because we don't have a great way to filter products by platform when getting runs?

[foolip]

@KyleJu do you have background on why there are different products instead of using the platform field?

[gsnedders]

I presume some of the reason is that if we used the platform field than the homepage and Interop and BSF would inconsistently use different platforms—because I don't believe we have any easy way to filter these by platform for a single run?

[KyleJu]

@KyleJu do you have background on why there are different products instead of using the platform field?

There is no particular reason on top of my head. ChromeAndroid, ChomeIOS run results are generated and manually uploaded separately to wpt.fyi. Perhaps we should label the correct platform going forward

[gsnedders]

Ah, so safari-165%20preview-macos does work as a param (for example), but you can only specify OS if you also specify browser version. Which doesn't work if you, e.g., want to get latest runs for chrome-linux, firefox-linux, safari-macos, imagining a hypothetical world in which we have other OS runs.

[foolip]

@KyleJu is there some way using /api/runs to iterate all runs of a browser on a specific platform?

[KyleJu]

@KyleJu is there some way using /api/runs to iterate all runs of a browser on a specific platform?

One way I can think of is retrieve a list of run_ids through /api/runs and call /api/runs/{id}. The JSON response has os_name":"linux" field, e.g. https://wpt.fyi/api/runs/5184362994728960. Loop through all run_ids and filter based off os_name

[gsnedders]

5cadbbc has a comment reading "A temporary workaround; remove this check when chrome_android is mapped to chrome on wptrunner", which suggests we're viewing the use of multiple products here as a hack around other limitations. And we could always map chrome_android to chrome in the processor in wpt.fyi. It would probably be good to fully understand what all the limitations we need to fix are.

Clearly, being able to search for runs by browser + platform is important for many things (the default browsers, metrics), but what else is there?

[foolip]

@KyleJu so it sounds like filtering by platform isn't supported at the right layer. In order to keep serving the same front page, we'd need /api/runs to be able to return in a single API call Chrome on Linux, Edge on Windows, Firefox on Linux and Safari on macOS, without knowing what versions are current.

Do you think supporting this would be a simple matter of the syntax to express it, or is the underlying datastore query not going to be efficient?

[KyleJu]

@KyleJu so it sounds like filtering by platform isn't supported at the right layer. In order to keep serving the same front page, we'd need /api/runs to be able to return in a single API call Chrome on Linux, Edge on Windows, Firefox on Linux and Safari on macOS, without knowing what versions are current.

Do you think supporting this would be a simple matter of the syntax to express it, or is the underlying datastore query not going to be efficient?

I hope that it is a simple tweak from the product param in the api/runs. I added it to the Q2 backlog and it will be prioritized in the beginning of next Q!

[gsnedders]

We should also make the product builder work with the field, but I'd hope that's also easy!