Same PRs and WorkItems are exist in two release notes

[buildsree]

HI,

we have an ado release pipeline and I added a task to Generate Release Notes (Crossplatform). For this release pipeline we have 14 build artifacts associated with it. when i ran release pipeline for first time it shows all the modified work items and PRs which are changed which looks good. but when there is a change in one particular build I created a new release and queued, now i can see new release notes created which contains the worktimes and prs which are not touched from previous build. to cross check, i compared the build artifact in both releases which contains same id.

below is the script which i used in my release pipeline.

please suggest me how to get only delta changes from previous release to current release if there is a change in only particular build artifact. remaining un changed should be ignored

---

Notes for release {{releaseDetails.releaseDefinition.name}}

Release Number : {{releaseDetails.name}}
Compared Release Number : {{compareReleaseDetails.name}}

---

Associated Pull Requests

{{#forEach pullRequests}}
{{#if isFirst}} {{/if}}

• !{{this.pullRequestId}}
  {{/forEach}}

---

Associated Epics

{{#if this.relatedWorkItems}}
{{#forEach this.relatedWorkItems}}
{{#if (eq this.fields.[System.WorkItemType] 'Epic')}}

• #{{this.id}}
  {{/if}}
  {{/forEach}}
  {{else}}
  None
  {{/if}}

---

Associated Features

{{#if this.relatedWorkItems}}
{{#forEach this.relatedWorkItems}}
{{#if (eq this.fields.[System.WorkItemType] 'Feature')}}

• #{{this.id}}
  {{/if}}
  {{/forEach}}
  {{else}}
  None
  {{/if}}

---

Associated Requirements

{{#if this.relatedWorkItems}}
{{#forEach this.relatedWorkItems}}
{{#if (eq this.fields.[System.WorkItemType] 'Requirement')}}

• #{{this.id}}
  {{/if}}
  {{/forEach}}
  {{else}}
  None
  {{/if}}

---

Associated Bugfixes

{{#if this.relatedWorkItems}}
{{#forEach this.relatedWorkItems}}
{{#if (eq this.fields.[System.WorkItemType] 'Bug')}}

• #{{this.id}}
  {{/if}}
  {{/forEach}}
  {{else}}
  None
  {{/if}}

---

Associated WI with PRs, parents and children

{{#forEach this.workItems}}
{{#if isFirst}}### WorkItems {{/if}}

---

{{this.id}}

• WIT {{lookup this.fields 'System.WorkItemType'}} - #{{this.id}}
• Tags {{lookup this.fields 'System.Tags'}}
• Assigned {{#with (lookup this.fields 'System.AssignedTo')}} {{displayName}} {{/with}}
• Description {{truncate (removeBlankLines (removeTags (removeDivsWithStyle (lookup this.fields 'System.Description')))) 100}}
• ReproSteps {{truncate (removeBlankLines (removeTags (removeDivsWithStyle (lookup this.fields 'Microsoft.VSTS.TCM.ReproSteps')))) 100}}
• PRs
  {{#forEach this.relations}}
  {{#if (contains this.attributes.name 'Pull Request')}}
  {{#with (lookup_a_pullrequest ../../pullRequests this.url)}}
  • !{{this.pullRequestId}} - {{this.title}}
    {{/with}}
    {{/if}}
    {{/forEach}}
• Parents
  {{#forEach this.relations}}
  {{#if (contains this.attributes.name 'Parent')}}
  {{#with (lookup_a_work_item ../../relatedWorkItems this.url)}}
  #{{this.id}}
  {{#forEach this.relations}}
  {{#if (contains this.attributes.name 'Parent')}}
  {{#with (lookup_a_work_item ../../../../relatedWorkItems this.url)}}
  #{{this.id}}
  {{/with}}
  {{/if}}
  {{/forEach}}
  {{/with}}
  {{/if}}
  {{/forEach}}
  {{/forEach}}

[rfennell]

Are you running the task in Multistage YAML or within a Classic Release? - I ask as the discovery logic is different.

I would actually suggest building you release notes for each of your 14 projects as part of their build stages, and publish them as build artifacts, or to WIKI, and then consume them as a set for publishing during a release.

Trying to handle all the changes as part of the release phase rarely gives the results required

[buildsree]

We are using ado classic release and created seperate stage for release notes task.

[rfennell]

The logic that 'discovers' the associated WI/CS/PR in Classic release is created by myself, this is because Microsoft provide no APIs calls to compare releases. The logic

• It scans for previous successful releases (to the stage the task is in)
• It then for each artifact find the build number for the current release and use for the last success (to the stage)
• For each component it get the changes WI and CS between the two build numbers (using an MS provided API call)
• It merges all these Wi and CS lists
• and finally tries to find any associated PRs (using merge commit messages)

You can see this all logged out if you run the task the the pipeline variable system.debug=true set

I have found this process does not always give the expected results, there are so many different strategies people use

Hence, as I said above I find the most reliable to create release notes as part of the build process, we favour publishing to a WIKI, and then assemble what is need for the release from the set.

This conference video I did, may help

[buildsree]

HI Richard,

Thanks for the quick replay
we have yaml templets for build pipeline and same templates has been used for all the stages. so if we add release notes step to build pipeline it may create many entries in wiki for each build like feature brnach,dev.release.main and also consolidating all these would be difficult. even in release pipeline we have multiple states so we need this release note only for 1 particular stage and remaining we don't need it.

Is there any possibility that we can get accurate results from release pipeline based on artifacts information

Thanks,
Sreekanth

[rfennell]

Sorry, I don't think there is much I can do over the way the logic for Classic releases work, the PAI give nothing to work with beyond what I have described above,

All I can suggest is you look at the detailed logs seen when system.debug=true is set and try to see where the logic is going wrong for your needs. maybe that will give a clue to some filter or custom logic for your use case

[buildsree]

Thank you Richard

let me try with Azure Devops APIs using powershell if i can achieve this