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.
Related
TFS 16.131.27701.1
Working from a Release, a user can quickly find references to the Work Items included in that release, and a user can reference the Commits included within that Release.
Working from a Work Item or a Commit, is there any way to quickly find the Release that included it that delivered it to an environment?
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/
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.
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.
We have begun using the following branching structure in TFS 2010:
All changes so far have been performed in the Development branch, and all check-ins have been associated with a Task work item. The Tasks are all children either of a Bug or a Product Backlog Item work item. Each CI build is triggered for a particular changeset, and the changeset is associated with a Task, so we can manually figure out which Bug or PBI was just built.
Some time after the code has been built, deployed to our Integration environment and tested by the developer, it is merged to the Main branch. Obviously, more than one changeset may be merged to Main at the same time. The nightly build will build this code if we don't manually trigger the nightly before that. QA will later deploy one of these "Main" builds to the QA environment.
There may have been several builds of the Main branch since the last time QA have deployed. These builds are associated with the "Merge" changesets, not with the original changesets which were associated with the Tasks.
How do I determine the set of tasks which have been addressed by a given "Main" build, which is a build of a different branch than the one associated with the Task work items?
Once we've begun preparing for a release, we may very well need to make changes in the Release branch, which will complicate things further since we will be merging back from Release to Main, and the Release changesets will be associated with Tasks. Those will then be merged to Development, making life even more interesting!
P.S. The question "How to determine the work items associated with a source branch in TFS 2010?" comes close to asking the same question, but not quite.
Take a look at Jacob Ehn's blog post Automatically Merging Work Items in TFS 2010. He wrote a plug in that can be downloaded from codeplex. It will automatically associate the work items that were associated with the merged changesets. So when you merge to Main or Release the work items will be associated with the changesets in those branches, and the work items will be included in the build reports for builds off of those branches. The plug-in is super easy to deploy.
The other option is that you can build a custom workflow activity that you can run during your build that can traverse the merge history for each of the changesets that would normally be associated. It's essentially walking the tree starting with a known set of associated changesets. I would prefer this approach since you can let your developers worry about only needing to associate work items with the original changesets instead of having to also do it with merge changesets as well. This also allows you to get around having to deploy a custom work item policy as Bryan described in his suggestion.
I might have some sample code to get you started with traversing the merge history tree if you want to contact me at http://www.edsquared.com