I noticed that work items can be linked to a build. But I don't see a way to automatically link the work items to the build.
On pull requests, we require pull requests to be associated with a work item. When the pull request is complete, the work item is updated with a link to the commits.
If I look at a branches commit history in TFS, there is a build column. I assume that the build column would contain the build that the commit is in, but it is always blank.
We want to be able to look at a build and see what work items are contained in the build.
Is there a way to do this?
The “Automatic linking of a build with associated work items” feature was released in TFS 2017 Update 2. You could enable this feature by toggling the setting under Options in your build definition:
In this way, each successful build associated with the work item automatically appears in the development section of the work item form.
More information you can refer to the blog below:
https://blogs.msdn.microsoft.com/devops/2017/08/25/automatic-linking-work-items-to-builds/
Related
Is it possible to remove the associated change below (commit fb6916d) from this build?
I have consulted the documentation for the TFS web API, but it only told me how to list associated changes and not how to remove them.
Associated changes: it shows the different commits between current and previous build.
Work items linked to associated changes: it shows the work items related to associated commits.
One addition, if you have non-successful builds, (failed or partially succeeded), the commits will keep showing up. The commits are calculated to compare against the last fully successful build.
It's by designed. Sorry, not be able to remove them if there are different commits compared with previous build.
I am new to Azure DevOps, so perhaps this is a really simple question. When selecting a build (there are many) to deploy to production, it would be great if I could identify the user stories or tasks were included in that build. I want to be able to say what work is being deployed before it is live, or tell customers who are waiting for new features when that feature is live.
I have tried to write a script using the Azure DevOps API and can see my builds and pull requests. But how do I link them? Is there an existing tool to do this maybe? It would also be great to say given a user story id (e.g. 171171), you could say which build it appears in. Is this possible or do this without saving all of the data from the API and reading this cached version?
You can specify work items (Bugs, User Storys, ...) when commiting to the Git-Repo. This is done by Hashtag and the work item number (e.g. #1234). Visual Studio also has a UI support for this, which does the same.
The linked work items will automatically be display at the Build summery page.
Just add work items into commit. Here is different options: Linking Work Items to Git Branches, Commits, and Pull Requests
I've received a request to create a custom report email for our executives. When we do a major release they want a list of Features of that release. What i need to do is read the related Tasks to the release then traverse up parent nodes until i get to the features that are marked with a tag "Executive". My Issue is that I can't find any document on how get the "Work items linked to associated changes".
I've been able to just through to get the specific build
GET http://XXX.MYTFSSERVER.COM/tfs/Collection/Project/e5e632e2-ae70-41c9-9d72-6686d2375f14/_apis/build/Builds/69330
But I don't see any link to get the workitems associated to the build.
Releases already do this out-of-the-box. On the Work Items tab of a release, you can have it generate an email that contains all of the work items associated with that release relative to an earlier release.
There isn't any build-in way to achieve this such as through TFS work item query. You need to build a extension to get all work items of specific release and filter them later.
The steps to achieve that with extension:
Get specify release to get build id
Get work items of that build per build id
Get related work items
Filter the work items which you actually need
A detail simple code of extension to get work items of specific release that you can refer to this link: TFS 2017 Release Management: How to display parent PBI for Tasks under Release
In TFS, when I link a work item in a PR, the PR gets approved, merged and the a CI deployment is performed, then I bet TFS should be able to see that the linked workitem(s) have been deployed production. I shouldn't have to look into master or develop branch to see if the code I am looking for is in place.
So, when looking at that particular work item (in epic, on board, wherever) I should be able to see some kind of deployment status.
Is that an out-of-the-box feature or does that require a plugin?
Actually the "deployment status" can be checked with the linked Pull Request and commit.
Once the PR gets approved, merged and the CI deployment is performed, the code changes will be checked in. Normally we can check if the code changes are really there by navigating to the specific merged branch.
Actually, when you looking at that particular work item, you can check the linked PR and commit to know the deployment status.
When you link a work item in a PR which is not approved and
completed, then you can see that there is only a Pull
Request with the ID under the All Links tap in the work item.
Once the PR is approved and completed, you can see that there is a
commit linked to the work item.
So, when you see a corresponding Commit linked there, that means the changes are deployed. You can also double click the linked PR and commit to open them to see the change details.
Is there any way to either manually remove associated changesets and work items from completed build on Team Foundation Server?
For example: I check-in a changeset, but I make a mistake and I link it with wrong work item. Before I notice that, I create a release build which associates changesets and work items and automatically generates changelog. Now the wrong work item is associated with a build. To fix my mistake, I remove link between work item and changeset.
However, there is still link between my completed build and work item. Is there any way to remove the link via user interface or I have to dig down into the TFS API?
I tried to delete my completed build and start a new one, however the work items and changesets that were associated with the deleted build are not associated with new build (even if I deleted the previous build). Does anyone know how to force TFS to associate work items and changesets with the new build?
After doing some research I have stumbled upon this article (https://social.msdn.microsoft.com/Forums/en-US/76462cd5-070f-4fba-8206-550b5511ae68) where someone had similar problem. I have also checked the referenced article on http://www.woodwardweb.com/tfs_top_tip/tfs_top_tip_15.html.
After I deleted the last build, I have also checked the dignostic output from my build and found this line in the log:
Warning: Cannot find the last label 'XXXXXXXXXXXXXXXXXXXX': no changesets will be associated with the build.
And the name of the label that could not be found was exactly the name of the label, created by the deleted build.
TFS obviusly remembers the previous label somewhere.
I have checked the TFS collection database and voila, here is the solution:
Delete last few builds (and check the labels for those builds are deleted).
Connect to TFS collection database.
Open table tbl_BuildDefinition
Find the build definition for which you want to reassociate changesets and change values in LastBuildUri, LastGoodBuildUri and LastGoodBuildLabel where:
LastGoodBuildLabel is the actual label which will be the new baseline for associating changesets and work items with build,
LastGoodBuildUri is the ID of build that created the last label you have in your source history (you can find this in your build history)
LastBuildUri is the ID of last run build (same as LastGoodBuildUri)
Run the build. The work items and changesets that were associated with the deleted builds will be re-associated with the new build.