During a build we use a powershell script to retrieve our current iteration path. This iteration path should be used to create a work item if the build fails.
try
{
$Uri = "https://.../" + "_apis/work/TeamSettings/Iterations?`$timeframe=current&api-version=3.0"
Write-Host $Uri
$Response = Invoke-RestMethod -Method Get -UseDefaultCredentials -ContentType application/json -Uri $Uri
$IterationPath = $Response.value.path
Write-Host $IterationPath
Write-Host "##vso[task.setvariable variable=BUG_ITERATION]$IterationPath"
}
catch [Exception]
{
$ErrorMessage = $_.Exception.Message
Write-Warning "Cannot read iteration. $ErrorMessage"
return "99"
}
Then we added a refeerence to the BUG_ITERATION variable here:
But the build always fails, because of this:
##[warning]Failed to create work item for build failure: TF401346: Invalid Area/Iteration id given for work item -1, field 'System.IterationId'.
I played around for a bit now, and it apears, it does interprets the build variable on build initialization and it doesn't matter anymore, what I write into it during build. The reason why I think that is, because it does recognise it, if I hardcode it like this:
Is there anything I can do to solve this?



In Azure DevOps, there is a difference between the path and the ID of an area or iteration. The error message you are getting is that
Test\Release 13\Iteration 175is not a valid ID for an iteration.You will need to make an API call to get the ID of the iteration. Then you can use the ID in place of the path and it should work. The API call you will need to make to get the ID is Get Classification Node. This endpoint allows you pass in the path of the iteration and returns a JSON object with the ID of it.