Open chases2 opened 1 year ago
/assing
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
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.