Once the PR is approved I want to automatically advance the state of the linked work item, but I don't want it to be marked as "complete". Instead I'd like the work item state to be "ready for testing" (still in progress).
For now, work item state can only be changed as complete when merging a PR.
And there has an user voice Customize Work Item State after PR is closed which suggests this feature, you can vote and follow up.
The work around for now is changing the linked work item(s) through CI build (after completing the PR). Detail work flow as follow:
Add a CI build to trigger automatically after the target branch has new commit(s). And add a PowerShell task to update the linked work items state by REST API.
When PR is completed, CI build will be triggered automcally. And the linked work items state will be updated.
You can try to use
Add a rule to a work item type
https://learn.microsoft.com/en-us/azure/devops/organizations/settings/work/custom-rules?view=azure-devops
Create service hook and cosume it later using azure function or logic app https://learn.microsoft.com/en-us/azure/devops/service-hooks/overview?view=azure-devops
Related
After reading through the End-to-End traceability documentation our team is finding it difficult to accomplish the final step in this list:
Developers create a branch or PR on a work item (in this case, a Task)
When the PR is completed and the branch merged, the work item shows the build
When the build artifact is released, the work item shows the deployment environments
All of that works great, but the final step is:
Show the builds and deployments on all parent tasks of the work item i.e., the Feature work item and the User Story work item.
Is that not possible? Or is there a rule or template that we could write that would automatically copy development links up the hierarchical chain so that developers and business can see the traceability across all associated work items?
Conversely, are we intended to manually link all development links to all work items?
Based on my understanding, you want parent work items to display builds and deployments tracked by child work items.
Testing on my side, the parent work items will not show the builds and deployments tracked by the child work items. DevOps currently does not support such feature.
We recommend that you could request this feature on: https://developercommunity.visualstudio.com/report?space=21&entry=suggestion. Voting helps increase the priority of the issue by consolidating customer impact under one feedback.
I have a build pipeline with a trigger on new branch creation. The trigger works fine with me creating a new branch and linking a workitem task to the new branch.
I have tried to run the query through the API to retrieve the workitem associated to the build but it always comes back blank. I can retrieve the list of workitems in the project no problem.
The URI I am using is:
https://dev.azure.com/{instance}/{project}/_apis/build/builds/{build id}/workitems?api-version=6.0
This returns a blank value. If I remove the "workitems" then I get a list of all the builds with one of the entries matching the build id. The PAT I am using has full access to the project (currently testing so have not been specific for the access).
This is the last step for me to complete and I can piece the whole puzzle.
UPDATE1: I have now noticed that in the pipeline log there is no related work item even though I create the branch from within the work item.
UPDATE2: I notice if I do a commit and associated the work item then the build lists the related work item. Does not appear to work when creating a new branch, only comitting to that new branch
Build pipeline adds related work items by reading the work items associated with the checkout commit.
I have now noticed that in the pipeline log there is no related work item even though I create the branch from within the work item.
When you create the new branch in work item, you need to change the build branch in Build Pipeline.
Then the build will use the newly created branch to build pipeline, the work items will relate to the Build.
When you run the Rest API: Builds - Get Build Work Items Refs, it will show the related work item.
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/workitems?api-version=6.0
I'm using Azure DevOps for both planning and coding,
Now when PR with attached issue (task)is merged, task is set to "Closed" automatically (I use project template based on Agile)
Is there a way to change it, e.g. I'd like my custom status "Ready for deploy" to be set instead of "Closed"?
This is currently controlled by the PR Compeltion Settings:
Unfortunately, the (feature) you're looking for is not presently supported, you can't handle the work item state when you check "Complete linked work item after merging"
Here is a related UserVoice in Microsoft Developer Community site: Customize Work Item State after PR is closed.
You can vote up and add your comment there. This User Voice is already Under Review.
As workaround you could try to use Service Hook to get the PR event and change the work item state to what you want.
In Azure DevOps, when creating a Pull Request, it's possible to associate work items (Product Backlog Items, Bugs, Tasks, etc). When this happens, the state of the work item is automatically set to Done.
Is that configurable? We would like to associate work items and have them NOT change state.
I've looked through the Project Configuration, Team Configuration, and the Process Configuration and there appears to be no setting relevant to this action.
If you want that the work items will not be changed to Done state you can uncheck the checkbox when you complete the PR:
If you want that the work items will be changed to another state, is not possible yet, this is not configurable, there is an open Feature Request about it, you can upvote it.
Edit: Microsoft added this feature in Sprint 174 with a preview access:
Starting in sprint 174, we have a new feature that allows you to set
the work items to the desired state when the pull request is merged
and completed. To do this, we scan the pull request description and
look for the state value followed by the #mention of the work item(s).
In this example, we are setting two user stories to Resolved and
closing two tasks.
https://devblogs.microsoft.com/devops/new-in-azure-boards-sprint-174/
We would like to link a TFS work item to a Release so we can easily, with one click from the Release, open a TFS item that contains more info about this release. Info like Release Notes etc.
Is it possible? A release has these variables that can be set when the release is created but they won't hold a (clickable link).
We cannot link work items for an existing release for now, there's already a user voice submitted here to suggest the feature, you can go and vote it up or submit a new one to achieve that in future release.
However you can link work items from changeset, try below steps:
Associate the work items to a changeset when you check in the changes
Then enable Automatically link new work in this build under Option in the build pipeline. Thus when a build completes successfully, it will create links to all work items linked to associated changes. See Automatic linking work items to builds for details.
Create a release pipeline and set the build which created in step2 as the artifacts source (For CI/CD).
You can also enable Report deployment status to Work for the stages under Option in the release pipeline (For set the repository as artifacts source ), thus when the stage completes, it will create links to all work items linked to associated changes.
Please note that in the release summary, it compares the current release with the previous release and then displays the newly added work items associated with changesets. So if you create two releases with the same artifacts source, then the second release will not include the work items... You can reference this thread for details: In TFS 2018, how do I get linked work items to show up in a release?