Azure DevOps - Traceability of ALL Work Items contained in a given release

I need to have full traceability between PRs and Releases -- I want to be able to see which work items were implemented in which release.

Azure DevOps apparently has a limit of 100 commits - which seems completely arbitrary/random. More info here: Azure DevOps PR message - "Work items only from the first 100 commits will be linked"?

My expectation: I use GitFlow, so I create a pull request from e.g. release/0.20.0 to main and expect to see all work items attached to the PRs since the last release (i.e. the PR from release/0.19.0 to main). I use a release pipeline, where I can also trace the associated work items -- but also here, it's limited to 100 commits!

My questions:

• Can this limit be increased so the work items from ALL commits are taken into account (not just the first 100)? 100 commits is not a lot, and I don't want to start squashing.
• Does this take into account the commits and/or the actual pull requests?
• Is there an alternate automated way of associating the qualifying work items with a given release?
• I noticed that work items which are mentioned in the PR description are also added (if they fall within 100 commits). We sometimes mention 'follow-up' work items in PR descriptions. Including these seems like unexpected/unwanted behaviour to me. Thoughts?

You should be able to easily achieve this with a simple Git command and script filter. Here's a template of an example using Bash:

git log <target>..<source> | grep "<Work-Item-Text>"

A working example might be:

git log main..release/0.20.0 | grep "Related work items:"

If your PRs also include the work items, or if only your PRs contain the work items, you could further filter based on PRs only:

git log main..release/0.20.0 --grep="Merged PR" | grep "Related work items:"

Notes:

1. In your case before the PR is completed, <source> is release/0.20.0 and <target> is main. If you have already completed the PR, then you could use the second parent of the merge commit as <source>, and the first parent of the merge commit as <target>.
2. The 2 dots (..) in the log command mean it should only consider the changes on the source branch that aren't reachable by the target. If you use 3 dots there, it would consider changes on both the target and the source branch. (More details here.) In Git Flow, release should always be fully ahead of main before it is merged in, so in your case it shouldn't matter whether you use 2 or 3 dots in that command. (If it does make a difference, then you may have an error in your Git Flow process, such as forgetting to merge a hotfix or main back up into release.)

Caveat: The above command is only looking at the commit message details, which is "locked in" at the moment the PR is completed. If you were to add a work item to a Pull Request after the PR is completed, then it won't show up in the commit message in the repo, but it would show up in your question's scenario if it's in the top 100 commits getting merged in. At our organization we have an automated pipeline that triggers every time our release branch is updated. To get around the problem of possibly editing work items after PR completion, the pipeline runs only the first half of the command above:

git log main..release/0.20.0 --grep="Merged PR"

And then loops through each of those commits to parse out the PR number, and then uses the AzDO API to go get information about each PR, including who made it, all of the work items associated with it, the state of each of those items, and then it generates a report with links to every PR and work item included in the release. This "Release Content" report is then sent to the appropriate channels for review.