Get work items since last release, including items linked to current build

[pvanhekke]

I have a use case which I cannot get to work, so I am wondering if there is a combination of configuration options that can make it happen.

Situation:

• there is a previous release (on master, identified by tag 'release', and stage 'release')
• since the last release build, some PRs with linked WIs have been merged
• current build runs from a PR, and this PR also has one or more WIs linked (release notes task runs in a stage 'prepare_release')

Attempt 1 - With the following configuration, I can get the WIs from already merged PRs, but not the WIs from the current build

checkStage: true
overrideStageName: 'release'
tags: 'release'

Attempt 2 - With checkStage: false, I can get the WIs from the PR that triggered the current build, but obviously the earlier PRs are not considered.

Zooming in a bit more on Attempt 1, in the debug log for a simple example with no previous merged PRs, I can see that the 2 work items for the current PR (1482317) are recognized and added, but somehow they don't show up in the Totals:

Enriching known Pull Requests
##vso[task.debug]Checking for tags for 1482317
##vso[task.debug]Added 2 work items for 1482317
##vso[task.debug]Added 8 commits for 1482317, note this includes commits on the PR source branch not associated directly with the build
Total Builds: [0]
Total Commits: [7]
Total Workitems: [0]
Total Related Workitems (Parent/Children): [0]
Total Release Tests: [0]
Total Tests: [0]
Total Manual Test Runs: [0]
Total Manual Test Configurations: [0]
Total Pull Requests: [1]
Total Indirect Pull Requests: [0]
Total Associated Test WI: [0]
Total Published Artifacts: [2]
Total Consumed Artifacts: [1]
Total WIQL Workitems: [0]

Other things I've tried

• enable checkForManuallyLinkedWI -> this returns every WI for every merged PR ever in this repo
• try without tags or overrideStageName -> previous release can not be found, all WIs in history are included

Any suggestions on how I can get this to work?

[rfennell]

Can I check are you using Classic Release or Multistage YAML?

If the former I would expect the settings to be

overrideStageName: 'release'

For the latter you need

checkStage: true # needed to enable multi stage processing 
overrideStageName: 'release'

In both cases, all that is done is

1. The current stage/environment name is overridden with the overrideStageName.
2. An attempt is made to find the build ID last successful release to the overrideStageName - look for log messages like Getting items associated the builds since the last successful build to the stage
3. Next -
   • For Multistage YAML a call is then made to the Azure DevOps REST endpoints getChangesBetweenBuilds and getWorkItemsBetweenBuilds to get a list of what has changed between the current build and last successful. What this returns is beyond my control
   • For Classic Release it is harder, as Microsoft provide no APIs to get the changes. I have to make many API calls to find the artifacts associated with the past release and do compares for each of these, merging the results.

[pvanhekke]

I am using a Multistage YAML.

For step 1 and 2, the log shows that indeed the correct build ID of the last successful release is found

...
Comparing 12780661 against 12814225
Considering build
Found required stage Create Release in the state 2 with the result 0 state for build 12780661
Using the build 12780661
Getting the details between 12780661 and 12814225
...

For step 3, so if these Azure DevOps endpoints only include the changes/WIs between the builds, I would need to find another way to either link the WIs for the current PR to an earlier commit in the PR, or to somehow add them manually. Would there be e.g. a WIQL query or any other way to achieve this?

[rfennell]

So it looks like the BuildID discovery is working, so that is a good start.

As to PRs, it is limitation of this AZDO REST API that it only provides APIs for comparing two pipeline runs (of the same definition) and listing WI and Commits. Any attempt to discover associated PRs is done using logic I created, this logic is far from perfect and does not handle all the possible merge models that a team might use.

It is exactly for this reason that I added the WIQL option, a number of teams have found it easier to express the associated WI via WIQL and inject theses values into the release notes, as opposed to using the AZDO API calls to find associations

[pvanhekke]

Thanks for the clarification! I will give the WIQL approach a shot when I have some time, and if I manage to get my use case to work, I'll update here as well.