GoogleCloudPlatform / testgrid

Apache License 2.0
193 stars 68 forks source link

TestGrid API: Implement Dashboard Tab Endpoint #1200

Open chases2 opened 1 year ago

chases2 commented 1 year ago

Currently, in the TestGrid API, you can look at a dashboard's tabs.

http://testgrid-data.k8s.io/api/v1/dashboards/sig-testing-misc/tabs

However, if you want to know anything about a particular tab, that info appears to be missing

http://testgrid-data.k8s.io/api/v1/dashboards/sig-testing-misc/tabs/branchprotector -> Doesn't work!

Instead, you can only grab the full data in a tab with deeper calls:

http://testgrid-data.k8s.io/api/v1/dashboards/sig-testing-misc/tabs/branchprotector/headers http://testgrid-data.k8s.io/api/v1/dashboards/sig-testing-misc/tabs/branchprotector/rows

This doesn't let us show useful tab data, like a tab's result source, its primary grouping, or what the extra headers configured on the tab even mean.

Please implement the missing method. You'll want to write the proto definition first, and then implement it (likely in 2 PRs).

Adding a New Method

TestGrid's API is defined with this proto. The proto only defines the shape of the API data, so multiple programs can use it.

You'll need to add a new RPC method, the GetDashboardTab response to include the new data. Design the new endpoint however you see fit to include useful data. "Result Source" and "Primary Grouping" are good places to start. If you're not sure if something should be included, feel free to skip it for now. Adding to a proto later on is much easier than deprecating and deleting a field.

DO NOT simply import or blindly copy the entire config proto object. Instead, only include fields that you want to show currently. The config includes all configuration, backend and frontend, useful and not, deprecated and widely-used. The API should only expose information to end-users that they actually care about, not backend implementation details.

For example, TestGrid's backend has Dashboard Tabs that are a view of a particular Test Group, a set of configurations on a result and how it should be regularly updated. The updater uses this a lot, but the end-user can't see and shouldn't have to worry about Test Groups. They just see Tabs, with some results on them.

NOTE: When you've changed the proto, do not worry about running "protoc" directly. You can regenerate the go code with this command:

bazel run //hack:update-protos

Updating the API

The API that actually emits this data is here. I leave this one more open-ended, since there are a lot of examples in config.go and config_test.go to reference. Like the other methods there, I recommend implementing and testing it as an RPC method, and then writing a wrapper to allow it to be accessed via HTTP.

SumantxD commented 1 year ago

/assing

ankur12-1610 commented 1 year ago

Data can be represented in the JSON format in the following manner:

data: {
    primary-group: {},
    result-source: { this will include GCS prefix, for fall back case fetch GCS prefix of test group },
    headers: {},
    enum: {}
}

@chases2 @michelle192837