Automatically updating fields in runs

This is a guide showing how to update fields in runs from automated test equipment or analysis workflows.

Get the fields

First thing you want to do is get the fields that exist in the run(s) you're trying to update:

Query
Response
Query
{
run(id: 419) {
id steps {
id fields {
id name value _etag
}
}
}
}
Response
{
"data": {
"run": {
"id": 419,
"steps": [
{
"id": 1429,
"fields": [
{
"id": 1461,
"name": "required_field",
"value": null,
"type": "STRING",
"_etag": "066b1eb08dab44d6925d7bbd899e92cf"
},
{
"id": 1462,
"name": "pass_fail",
"value": null,
"type": "BOOLEAN",
"_etag": "066b1eb08dab44d6925d7bbd899e92cf"
},
{
"id": 1463,
"name": "quality",
"value": null,
"type": "SIGNOFF",
"_etag": "066b1eb08dab44d6925d7bbd899e92cf"
}
]
},
...

This will return a list of steps within that run, and the fields within those steps. Find the field that you want to update. From the example response (Response tab) above, let's say we want to updated field 1462 because our test equipment is able to determine pass/fail easily. Here's the query you'll use:

mutation {
updateRunStepFieldValue(input: {
id: 1462,
value: true,
etag: "066b1eb08dab44d6925d7bbd899e92cf"
}) {
runStepField {
id value
}
}
}

What does this include? Because we're updating data, this is a mutation . The mutation we're using is called updateRunStepFieldValue. The id of the field is 1462 and the value we're setting is true. And finally, we'll include the etag of the original field. The etag prevent accidental data overwrites by enforcing concurrency control. After running the mutation, we'll get back the id and the updated value of the field in the response.