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.
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 understand how to link work items to a build, but when viewing release results, I see a section listed for Work Items, and that you can compare work items linked from an artifact in different releases.
What I don't understand is how to get the work item linked from a build to show up in the release that was triggered to run from the build.
How can I do such a thing?
For example, in this post, they show their build results with work items linked, and then show their release with other work items linked. What steps do I have to take to make that happen for me?
To get linked work items to show up in a release, you just need to set the builds (show up work items) or the specific sources which associate work items with the changesets as artifact sources.
In the release summary, it compares the current release with the previous release and then displays the newly added work items associated with changesets.
Try below steps to achieve your requirement:
Create a build definition A, map sources to include the
files/items will be changed in source control
Edit and modify the files/items, check in the changes with work
items associated. (e.g. Task1 here)
Trigger build definition A to queue a build1 (Task1 should
display in Build summary)
Create a release definition B, and add build definition A as
the artifact source, then create a release. (Task1 should display
in release summary)
Edit and modify the files/items second time, check in the changes
with work items associated. (e.g. Task2 here)
Trigger build definition A to queue a build2 (Task2 should
display in Build summary)
Do not create release here
Edit and modify the files/items third time, check in the changes
with work items associated. (e.g. Task3 here)
Trigger build definition A to queue a build3 (Task3 should
display in Build summary)
Create a release now, Task2 and Task3 will display in the
release summary.
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/
For my project requirement i have applied the label to source code modified in TFS2010.Now at the time of build i am supplying file name to do the build and deployment and these files are getting picked up as per label applied.But this approach will not tell me which file was modified in which backlog.Is there any commnd line available in TFS to get the product backlog item asscociated with the files modified be developer?
In build definition you have the parameter Associate Changesets and Work Items (under the Process tab and in the Advanced node); this parameter should be set to true
If your development team has been checking-in changes and associating each checkin with the relevent Work Item then the data is in there. The build by default will update the Integrated In value in the related work item, and in 2012+ all parent work items. So if you have been doing that the data is there.
There is however no OOB report to retrieve it. You can use the API or the Warehouse to get the data out.
Scenario: Dev team has lets say 10 Work items. They resolve 8 work items and that needed changes to 50 files (checked out and checked in and during check in are associated to Work Items). They also worked on remaining 2 work items and fixed and checked in 5 files, but the work items are not completely done, so not resolved yet. Now I want to create a build with the 50 files only which are associated to the 8 Resolved Work items (and exclude from build the 5 files for the 2 unresolved bugs) . Is there a way to do that in TFS 2010?
TFS builds from changesets, so you need to find out the changesets associated with the work items you need to include/exclude. Simply browsing the history may suffice, but you may have to inspect what changesets are associated with the work items.
if you're lucky those changesets that you don't want to have included in the build are later in History, it's simply a matter of setting up a workspace containing only the history up until the changeset you need. If you're using Team Build, the default build process has parameter GetVersion that you can set to the changeset you want to build when queuing. If it's manual, you'll have to do a
tf get /version:C<changeset number>
(UPDATED) If on the other hand the order of checkins have been mixed (some of the changes that you need to exclude have been done prior to some that you need to include), the best way would be to create a branch, and then only merge the changesets you need to include to that branch. Then you can simply build from the latest version on that branch.
1)Using History, find the latest changeset with code you need (the closest prior to one you need to exclude)
2) Create a branch based on that version.
3) Do a selective merge of the other changesets you will need included in your build, skipping those you don't want.
4) Build from the Latest version on that branch.