In Azure Devops "Classic" pipelines, there's a section in the pipeline Options menu where you can turn on a feature to automatically create a work item on pipeline failure. However, in the new YAML pipelines, this feature is not present in the options menu. Is this option still available in some way, or is it not supported for YAML pipelines?
1 Answers
Although this option is not currently available via the GUI for YAML pipelines, it is nevertheless still functional under the hood - there's just not an easy way to turn it on. You can, however, do so by utilizing the Azure DevOps REST API.
First you'll want to know the name of your Azure DevOps organization, project, and the pipeline's Definition ID, which is a query string parameter on the URL when you're viewing a given pipeline, e.g. https://dev.azure.com/{organization}/{project}/_build?definitionId={definition id}
. Then, you'll want to send a GET request to the Pipelines API for that ID, using this URL format: https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{definition id}?api-version=5.1
. For authentication, you should be able to use Basic auth, leaving the username blank and using an appropriately scoped Personal Access Token as the password.
If your request is successful, you should get a response containing a large JSON object which describes the pipeline in question. There's a lot there that isn't relevant, but what we're looking for is near the top: there's an options
array which includes the following element:
...
{
"enabled": false,
"definition": {
"id": "a9db38f9-9fdc-478c-b0f9-464221e58316"
},
"inputs": {
"workItemType": "Task",
"assignToRequestor": "true",
"additionalFields": "{}"
}
},
...
That ID of "a9db38f9-9fdc-478c-b0f9-464221e58316"
appears to be static across all pipelines, and uniquely identifies the option to create a work item on failure. If we edit the JSON to change "enabled": false"
to true
(and set any other desired options in the inputs
fields), we can now take the entirety of the JSON response from our GET request, and use it as the body of a second API call to the same URL, this time a PUT
request. If all was correct, you should see your updated changes reflected in the response from the PUT
.
It's a bit clunky because there's still no way to verify that the option is turned on through the web UI, but until Microsoft updates the UI to include this feature, it's the best option available. One more handy tip is that if you already had a classic mode pipeline where you'd added Additional Fields or other customizations to the UI, you can do an API GET
on that pipeline to extract the exact JSON for those settings and use them to inform your PUT
to your YAML pipeline.

- 4,707
- 7
- 35
- 63
-
In my case, the GET request is successful, but I have no `options` array returned. – Maxime Gélinas Nov 12 '20 at 17:59
-
That's strange! I've been using this trick to update the fields being populated on my auto-generated work items as recently as yesterday. – Sam Hanley Nov 13 '20 at 14:30
-
Our account has been created before Azure DevOps has been call that way meaning our URL is still {org}.visualstudio.com. Could it be the reason? – Maxime Gélinas Nov 13 '20 at 14:57
-
I don't think so - that's actually the case for my org too. I don't know why your response body would look different than mine. – Sam Hanley Nov 13 '20 at 15:01
-
That said, even if your org uses the {org}.visualstudio.com URL format, you can still also use the new one - perhaps try substituting your values into the exact URL format from my post? Are you possibly calling with a different `api-version` than the 5.1 specified in my call? – Sam Hanley Nov 13 '20 at 15:07
-
I used the exact URL in the first place. I decied to use a classic pipeline instead of a yml one until this feature is available in yml. Thanks for your time I appreciate it. – Maxime Gélinas Nov 13 '20 at 15:53
-
I get a HTTP 405 response when I send the PATCH request. The response says "Message": "The requested resource does not support http method 'PATCH'." – Kangkan Jan 28 '21 at 04:36
-
Hmm, perhaps the API has changed - seems like it now accepts a `PUT`. Updating the answer now. – Sam Hanley Jan 28 '21 at 14:32