-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not updating multiple Work Items in the same release #66
Comments
Created another Release today that had two related WITs attached. Below is the debug log (minus some sensitive information related to my company/employees (used [BLAH BLAH BLAH])): Work ItemsDebug logs
|
@BlueBasher is this still an active project? |
Yes it is still active. Currently have very little time though to do any coding on it. Happy to accept any PR though.. ;) |
@BlueBasher looking at this https://docs.microsoft.com/en-us/rest/api/azure/devops/build/builds/get%20build%20work%20items%20refs?view=azure-devops-rest-5.1 There is a |
You are correct, the Access Token for publishing the extension was expired.. |
@BlueBasher Ran another release today with 4 work items and got the same results here -#66 (comment) It only updated one work item and the If I knew how to run this type of project, I would love to submit a PR but never worked with VSTS extensions. |
In your screenshot it shows that it compares the release with previous deployment Release-405. |
@BlueBasher I checked that box and ran a new release with two work items. None of them updated.
|
Hi @BlueBasher, I have the same bug as the last two messages. Do you know if this bug has been fixed? |
As far as I know there should not be any bug that causes workitems not to be updated. |
Thanks @BlueBasher for your quick reply! I'm trying to use your extension with Azure yaml pipelines like this : task: WorkItemUpdater@3
displayName: "WorkItem Updater"
inputs:
workitemsSource: Build
workItemType: Task
updateAssignedTo: Never
linkBuild: true
comment: "TEST"
continueOnError: true When I launch my pipeline, the work item is recognised by azure but not by WorkItemUpdater :
Do you know why it doesn't work? Have I forgotten something? |
@BlueBasher I am getting the same issue now. It was working earlier. I get the "No workitems found to update." in the logs. I applied Filter as well. |
Hi, TLDR: Source is here By using it here without specifying the artifact WorkItemUpdater/src/WorkItemUpdater.ts Line 194 in 8d258ef
We are only fetching the items related to the main one. It really isn't well documented and I had to explore myself the REST api to draw that conclusion. The fix would be to loop on each artifact-alias of the release, maybe with I did it with a hardcoded artifact-list on a powershell script at the moment. |
Hello,
Thank you very much for answering my questions!
Power shell forever 😊
Mykola Bieliashov
DevOps Engineer
***@***.******@***.***>
+380504846811
techfabric.com
***@***.***
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
From: Paul Roy ***@***.***>
Sent: Tuesday, September 24, 2024 4:11 PM
To: BlueBasher/WorkItemUpdater ***@***.***>
Cc: Nikolay Bieliashov ***@***.***>; Comment ***@***.***>
Subject: Re: [BlueBasher/WorkItemUpdater] Not updating multiple Work Items in the same release (#66)
Hi,
I encounter the same issue and I found why.
TLDR:getReleaseWorkItems only fetches the items of the main artifact
Source is here
getReleaseWorkItemsRefs(project: string, releaseId: number, baseReleaseId?: number, top?: number, artifactAlias?: string): Promise<ReleaseInterfaces.ReleaseWorkItemRef[]>;
https://github.com/microsoft/azure-devops-node-api/blob/efcb995db93fc08d6e0e731ce9ca76e9747723a7/api/ReleaseApi.ts#L109
By using it here without specifying the artifact
https://github.com/BlueBasher/WorkItemUpdater/blob/8d258ef9d80ad01eb7cd7dd4b21a77b0d76e3eb6/src/WorkItemUpdater.ts#L194
We are only fetching the items related to the main one. It really isn't well documented and I had to explore myself the REST api to draw that conclusion.
The fix would be to loop on each artifact-alias of the release, maybe with
getAgentArtifactDefinitions(project: string, releaseId: number): Promise<ReleaseInterfaces.AgentArtifactDefinition[]>;
https://github.com/microsoft/azure-devops-node-api/blob/efcb995db93fc08d6e0e731ce9ca76e9747723a7/api/ReleaseApi.ts#L22
This is what I did with a powershell script at the moment.
—
Reply to this email directly, view it on GitHub<#66 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AWQYT6BRNOMEPNBLMQLIPUDZYFQGVAVCNFSM6AAAAABMOJKRMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZRGIZTEOBYGM>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Good afternoon |
Hey, Oleg!
I used advice from Paul, and it works properly.
I didn't check if something was fixed on ADO side, honestly speaking.
Mykola Bieliashov
DevOps Engineer
***@***.******@***.***>
+380504846811
techfabric.com
[cid:39057cb0-5ea0-4b3a-9c64-5dbbbd12ba6b]
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
…________________________________
From: Oleg Solonko ***@***.***>
Sent: Thursday, January 30, 2025 13:44
To: BlueBasher/WorkItemUpdater ***@***.***>
Cc: Nikolay Bieliashov ***@***.***>; Comment ***@***.***>
Subject: Re: [BlueBasher/WorkItemUpdater] Not updating multiple Work Items in the same release (#66)
Good afternoon
Will a fix be prepared for this issue?
—
Reply to this email directly, view it on GitHub<#66 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AWQYT6HD2OVNJAYNQTUQDP32NIGCFAVCNFSM6AAAAABMOJKRMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMRUGI3DKMRYGU>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Hello, We could technically list the artifacts and fetch the work items for each artifact on our end though. I ended up using powershell to do more specific work item rules and I didn't took the time to make a PR but do not hesitate if you want to @solonkooi |
@PaulARoy Thanks for sharing your approach! Listing artifacts and fetching work items for each one sounds like a reasonable solution. Would you mind sharing a rough implementation of how you achieved it with PowerShell? It could be helpful for us to understand the approach better. |
Sure, here it is with custom rules (I removed some checks to make it easier to read) : $AzureDevOpsPAT = $env:AZUREPAT
$OrganizationName = "[redacted]"
$Project = "[redacted]"
$AzureDevOpsAuthenticationHeader = @{Authorization = 'Basic ' + [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$($AzureDevOpsPAT)")) }
$UriOrgaProject = "https://$($OrganizationName).vsrm.visualstudio.com/$($Project)"
$definitionId = $env:RELEASE_DEFINITIONID
$definitionEnvironmentId = $env:RELEASE_DEFINITIONENVIRONMENTID
$releaseId = $env:RELEASE_RELEASEID
$workItemTypes = @("Bug", "Technical Bug", "Product Backlog Item", "Technical Story")
$uriDeployments = $UriOrgaProject + "/_apis/release/deployments?definitionId=$($definitionId)&definitionEnvironmentId=$($definitionEnvironmentId)&deploymentStatus=Succeeded&api-version=7.1"
$deployments = Invoke-RestMethod -Uri $uriDeployments -Method get -Headers $AzureDevOpsAuthenticationHeader
$baseReleaseId = $deployments.value[0].release.id # last succeeded deployment
$releaseUri = $UriOrgaProject + "/_apis/release/releases/$($releaseId)?api-version=7.1"
$release = Invoke-RestMethod -Uri $releaseUri -Method get -Headers $AzureDevOpsAuthenticationHeader
Write-Host "Deploying from release: $($baseReleaseId) to release: $($releaseId)"
Foreach ($artifact in $release.artifacts)
{
try {
$uriWorkItems = $UriOrgaProject + "/_apis/release/releases/$($releaseId)/workitems?baseReleaseId=$($baseReleaseId)&artifactAlias=$($artifact.alias)&api-version=6.0-preview"
$workItems = Invoke-RestMethod -Uri $uriWorkItems -Method get -Headers $AzureDevOpsAuthenticationHeader
Foreach ($workItem in $workItems.value) {
$details = Invoke-RestMethod -Uri "https://dev.azure.com/$($OrganizationName)/$($Project)/_apis/wit/workitems/$($workItem.id)?fields=System.WorkItemType,System.Title,System.State&api-version=7.1" -Method get -Headers $AzureDevOpsAuthenticationHeader
Add-Member -InputObject $details -NotePropertyName "artifact" -NotePropertyValue $artifact.alias
If ($workItemTypes.Contains($details.fields.'System.WorkItemType')){
Write-Host "$($details.artifact): updating $($details.fields.'System.WorkItemType') $($details.id): ""$($details.fields.'System.Title')"" to State « To Validate »"
$uriUpdateWorkItem = "https://dev.azure.com/$($OrganizationName)/$($Project)/_apis/wit/workitems/$($details.id)?api-version=7.1"
If ($details.fields.'System.State' -eq "Done") {
Write-Host " [WARNING] Bypassing Done item"
}
Else {
$assignedTo = "[redacted]"
$Body = @(
@{
op = 'replace'
path = '/fields/System.State'
value = 'To Validate'
},
@{
op = 'add'
path = '/fields/System.AssignedTo'
value = $assignedTo
}
) | ConvertTo-Json -Depth 100 -Compress
$response = Invoke-RestMethod -Uri $uriUpdateWorkItem -Method patch -Headers $AzureDevOpsAuthenticationHeader -Body $Body -ContentType "application/json-patch+json; charset=utf-8"
}
}
}
}
catch {
Write-Host "An error occurred:"
Write-Host $_
}
} I should warn you that we are dependant on whether the base deployment info still exists because they are removed after x days (default is 30). |
@PaulARoy Thank you very much, this will help us a lot |
You're welcome! I must admit these APIs aren't perfectly documented, I had to find code from other github projects calling the ADO APIs to unlock these hidden mysteries. The difficult part was getting the items from release to release. I wonder if I didn't even decompile the .net client to find that call. Feel free to ask for any explanation or support! Reference of the API |
Can you provide some insight why my WorkItemUpdater is not updating multiple work items but just one every time?
Here are my settings configured:

Here is the log in VSTS showing one work item being updated. There were TWO work items in the release:

The text was updated successfully, but these errors were encountered: