How to limit associated work items in Azure DevOps YAML pipeline once PR is merged?

0
votes

I've been migrating build/release pipelines in Azure DevOps to the unified YAML format. Everything works as expected apart from the work items which are associated with CI builds once a PR is merged to the master branch. Here is the workflow:

  1. Developer raises PR to merge changes from feature branch into the master branch
  2. The PR has a build policy which executes the YAML pipeline against a test environment
  3. The PR is completed and the feature branch is merged into the master branch
  4. The YAML pipeline has a CI trigger for deployments to higher environments

For step 2 the triggered build shows whichever work items are associated with the PR:

enter image description here

However, for Step 4 the triggered CI build lists all work items in the master branch rather than just those associated with the PR:

enter image description here

Is there a way to only associate the work items which are associated with the PR to the CI build which is triggered once the feature branch is merged into master?

1
azure-devopsazure-devops-pipelinesazure-yaml-pipelinesazure-devops-yaml
Azure DevOps should automatically diff your merge to master and only associate the newly added work items. It sounds like you might have lost a common ancestor. Which type of merge are you performing when you merge into master? – Max Morrow
We're using merge (no fast forward). This merge strategy works as expected in the old build & release pipelines; release pipelines were associated with the expected work items. – ASH
Hm, that's really strange then. That should work just fine. – Max Morrow

1 Answers

0
votes

I can reproduce this issue and I found a similar ticket, they have reported it, you could follow this ticket to get the latest news.

If the build status is queue or running, then we create a new build, the new build will contain before build link work item. This is why the step 4 the triggered CI build lists all work items in the master branch rather than just those associated with the PR.

If all builds are completed, then we complete the pull request to trigger the CI build, it will be associated with the expected work items.

When all the builds were completed, I merged the PR to trigger the CI build, it just contain the pull request link work item.

Test result

enter image description here