How are "related" work items for pull requests determined in VSTS?

Question

I've recently discovered that work items linked to pull requests can be used when seeing which work items are associated with different deployments. That said, I want to make sure the related work items are accurate. I could link my work items manually, but in some cases there can be 50 different commits going out in a single squash merge commit. That is a lot of different commits to have to manually enter in.

I see VSTS (Azure Devops) tries to automatically add some related work items. The problem is that I do not know how these work items are being calculated right now. As you can see from the image below, you can have associated work items even if no code changes are detected. Can someone please shed some light on this? According to Fiddler, the API called for this in the VSTS api is:

// POST https://foobar.visualstudio.com/16e07dde-f652-4a64-93f1-3edb3d70d5e1/_apis/git/repositories/c9bd207c-bc6e-4e6c-aba9-8fd6aeb53946/commitsBatch 

{"$top":101,"itemVersion":{"versionOptions":0,"versionType":0,"version":"master"},"compareVersion":{"versionOptions":0,"versionType":0,"version":"users/v-username/140357_TestBranchForFeatureDeployment_ButWithLinks"}}

Answer 1

When you create the Pull Request, e.g from dev to master, it will detect the commits which differ between these 2 branches firstly. It is the commitsbatch api you saw from the Fiddler trace.

For work items listed in the pull request, it is the one which associated with the commit. When detecting the commits, the associated work items are detected and listed also. These are what you saw in the above screenshots you shared.

---

I think the you most concerned and confused should be why it display 100 commits but still said No file changes in this pull request.

Based on my known, it seems be the known limitation of Azure devops PR. See this thread which reported to us before.

For example take the following branches and commits:

feature/task-1:

commit e48b5a97d33abf733df656ebc2bf81cedccf7815

feature/task-2:

commit e48b5a97d33abf733df656ebc2bf81cedccf7815

commit 6a6c2db2c71a584bd07632c7387b7bee3fb32eea

If feature/task-1 and feature/task-2 are both Pull-Requested to develop, after feature/task-1 is merged, the pull request for feature/task-2 will still show changes from commits e48b5a97d33abf733df656ebc2bf81cedccf7815 and 6a6c2db2c71a584bd07632c7387b7bee3fb32eea even though e48b5a97d33abf733df656ebc2bf81cedccf7815 has already been merged into develop.

With this limitation, the commits still be detected, but since the file changes has been merged by other branch previously, so it will say no file changes. Also, the work items which associated with the commits are displayed.

Just check it and confirm whether it is what you are facing. If yes, try with the work around our engineer mentioned here.

Or you could raise the new ticket on that forum, to let the corresponding product group make focus on it.