Azure DevOps: Incomplete list of related workitems in build pipeline

[mrmscmike]

We are using GenerateReleaseNotes 💘 (XPlat version) with Azure DevOps Server 2020 Update 1.1 (18.181.31626.1) running locally on our server. As far as I know, we don't have a problem with GenerateReleaseNotes, but rather with DevOps itself. However, I am trying to understand the root cause, and for that reason it would be interesting to know some details about GenerateReleaseNotes.

We always add a link to one or more related work item when we commit. The work items are correctly linked to a commit. So far, so good.

I have a build pipeline that is running for the first time. There is no previous build. When running the pipeline, some of our work items are not added to the list of related work items:

DevOps lists over 50 items. To be exact, there are 78 items. However, when I manually check the commit history, I find 186 different work items associated with at least one commit. What could be the reason for 108 work items missing from this list?
I could not find anything that the missing work items have in common. In another test, I pushed a new commit linked to a new work item. When I run a new build for the first time (pipeline with no previous builds), the new linked work item is now listed under related work items. However, I am now getting 74 related work items. I was expecting to get 79 related work items. Does anyone know of a possible reason for this?

Is it correct that GenerateReleaseNotes lists the same work items for the release notes as DevOps lists in the related work items section?
How does DevOps find the related work items? Is there any way to debug this process?

Thanks in advance

[rfennell]

If a run is the first one for a given pipeline then the call my task uses to get the CS and WI are as follows (via the Node SDK)

globalCommits = await buildApi.getBuildChanges(teamProject, firstBuild.id, "", 5000);
globalWorkItems = await buildApi.getBuildWorkItemsRefs(teamProject, firstBuild.id, 5000);

These equate to

• https://docs.microsoft.com/en-us/rest/api/azure/devops/build/builds/get-build-changes?view=azure-devops-rest-6.0
• https://docs.microsoft.com/en-us/rest/api/azure/devops/build/builds/get-build-work-items-refs?view=azure-devops-rest-6.0

If it is a subsequent run then the calls are

 globalCommits = await buildApi.getChangesBetweenBuilds(teamProject, lastGoodBuildId, buildId);
 globalWorkItems = await buildApi.getWorkItemsBetweenBuilds(teamProject, lastGoodBuildId, buildId);

which equate to

• https://docs.microsoft.com/en-us/rest/api/azure/devops/build/builds/get-changes-between-builds?view=azure-devops-rest-6.0
• https://docs.microsoft.com/en-us/rest/api/azure/devops/build/builds/get-work-items-between-builds?view=azure-devops-rest-6.0

All I can suggest to make the API calls from a browser (they are just Gets), curl or postman and compare what is returned to UI.

[mrmscmike]

Thank you very much for your help. It is very interesting: I call ...workitems?api-version=6.0&$top=5000 and get fewer workitems than the UI shows. Using the API call, I get the first 61 in the same order they appear in the UI. The rest are simply not there...

When the build is complete, the list of related work items looks like this:

It looks like some workitems are still in progress. Isn't that strange? No agent is working and there is no other pipeline.

Thanks again

[mrmscmike]

I have spoken with Microsoft about this and I think the outcome might interest you as well:

I have an incomplete list of related work items in my build pipeline because the number of changes linked with a pipeline execution is limited to 250:

Let's say we have implemented a very important "Feature A". Now we continue working and make 250 more changes without ever mentioning "Feature A" again. In this case, when we run a build pipeline, "Feature A" will never be part of the related work items. This is especially bad if the list of related work items is later used, for example, to create release notes.

In my opinion, it is very dangerous and misleading that there is such a limit.

The limit for 250 changes was defined by the product group and is basically a threshold to prevent performance degradation.

I sincerely hope that Microsoft will remove this limit.

[jarodsmk]

Hey @mrmscmike -

I have spoken with Microsoft about this

Do you have any references to your discussion with MS? I'm currently experiencing an issue with the related workitem/commits and am trying to gain more context to resolve it since it's affecting my teams CI/CD process.

TIA!

[mrmscmike]

https://developercommunity.visualstudio.com/t/Incomplete-list-of-related-workitems-in-/10109420

https://stackoverflow.com/questions/72491130/azure-devops-incomplete-list-of-related-workitems-in-build-pipeline/73018219?noredirect=1#comment138259653_73018219

After the long discussion (see link), I was able to speak directly with the development team.
This conversation is private. However, to summarise, they confirmed the behaviour (limit of 250 work items) and told me that they will not change it.

I hope this helps.