We are currently using the on-premises version of TFS 2017 Update 1 (Version 15.112.26307.0) in combination with build agents that are on version 1.105.7.
When running a vNext build definition as a Batched Continuous Integration build on a Git repository hosted on TFS, we have found that the Source Version commit won't always show up in the build's Associated Changes list. We can observe both behaviours (this commit appearing, and this commit not appearing, in the build's Associated Changes list) during our work day , but have not yet been able to figure out exact repro steps that guarantee either behaviour.
Since we have branch policies configured on the branch being built, the Source Version commit is typically the merge commit generated by completing a Pull Request. If a Squash Merge is not used, then the individual commits within the Pull Request always show up in the build's Associated Changes. This is only an issue with the merge commit generated by completing a Pull Request, regardless of whether or not the Pull Request was completed with a Squash Merge.
This had not been an issue when we were using TFS 2015 Update 3, and only started occurring when we updated to TFS 2017 RTM. We had initially hoped that enabling TFS 2017 Update 1's new Merge Requirements branch policy of "Merge changes using a no fast-forward merge" would resolve this issue, but that has not been the case.
The reason this is a problem for us is because we have been relying on the build's Associated Work Items list in order to ensure that our work items' Integrated In Build fields are updated correctly, as per https://blogs.msdn.microsoft.com/tfssetup/2016/05/09/build-association-with-work-items-in-vnext/. However, if the Source Version commit doesn't show up in the Associated Changes list, and it was the only commit that was linked to a work item, then that work item doesn't show up in the build's Associated Work Items list, and thus doesn't get an updated Integrated In Build value.
We were wondering whether this is an issue that is resolved by using the latest build agents (version 2.112.0), or whether this issue also exists when using those agents?
Useful to allow tasks to be 'unassigned'
Cannot add TFS server group to Access Level
unable to see build step logs, tfs 2017
Package Manager and Extensions