First run (Initial Deployment) using GenerateReleaseNotes extension processes 1000 builds, not just last 1 successful

[astanley]

The very first time that GenerateReleaseNotes runs, in my Azure DevOps release pipeline, it appears to try and process EVERY commit on the entire history of the branch.

The develop branch has been in use on this project for ~2 years and over 1000+ builds have successfully run during that time (CI trigger is a pull request). So there are many thousands of changes that it is looking at.

I really just want the scope of my Initial Deployment to be "the last successful build that ran", not every build that ever ran. However it feels like this logic is internal to the extension, and no matter how much I fuss with config, I just can't get past this.

Help! Can someone help explain why?

Steps to reproduce:

1. I submit a PR from myTestBranch to develop (change = add a new helloWorld.txt)
2. The PR triggers myFooBarBuildPipeline (build pipeline) to run.
3. When the build pipeline completes, a CI trigger starts my release pipeline
4. My release pipeline runs the GenerateReleaseNotes extension and starts processing 1000+ builds

My configuration:

- task: richardfennellBM.BM-VSTS-XplatGenerateReleaseNotes.XplatGenerate-Release-Notes.XplatGenerateReleaseNotes@4
  displayName: 'Generate Release Notes (using Release Comparison API)'
  inputs:
    outputfile: '$(System.DefaultWorkingDirectory)/releasenotes.md'
    templateLocation: InLine
    inlinetemplate: |
     << omitted >>
    checkStage: false
    sortWi: true
    showOnlyPrimary: true
    dumpPayloadToConsole: true
    replaceFile: false
    getParentsAndChildren: true
    getAllParents: true
    checkForManuallyLinkedWI: false
    getPRDetails: false
    getTestedBy: false

Relevant log output from the run:

2024-05-22T20:40:06.7141060Z Getting the current release details
2024-05-22T20:40:06.8634855Z Show associated items for primary artifact only is set to false
2024-05-22T20:40:06.8635468Z Finding successful deployments
2024-05-22T20:40:06.9039963Z Getting all artifacts in the current release...
2024-05-22T20:40:06.9040184Z Found 1 artifacts for current release
2024-05-22T20:40:06.9040726Z Skipping fetching artifact in the most recent successful release as there isn't one. 
2024-05-22T20:40:06.9040962Z Looking at artifact [_myFooBarBuildPipeline]
2024-05-22T20:40:06.9041154Z Artifact type [Build]
2024-05-22T20:40:06.9041301Z Build Definition ID [1234] 										
2024-05-22T20:40:06.9041468Z Build Number: [20240522.55] 										
2024-05-22T20:40:06.9041611Z Is Primary: [true]
2024-05-22T20:40:06.9041830Z Looking for the [_myFooBarBuildPipeline] in the most recent successful release [Initial Deployment]
2024-05-22T20:40:06.9042147Z Found artifact [_myFooBarBuildPipeline] with build number [20240522.55] in release [Initial Deployment]
2024-05-22T20:40:06.9042434Z This is the first release so checking what commits and workitems are associated with artifacts 
2024-05-22T20:40:07.6999800Z Getting the details of build 112247
2024-05-22T20:40:07.9050522Z Getting the details of build 112221
2024-05-22T20:40:08.0828941Z Getting the details of build 112202
...

keeps going 1000 more builds ...

[rfennell]

The log line 2024-05-22T20:40:06.7141060Z Getting the current release details only occurs when you are running the task within a Classic Release, so my assumption is

• You have a build on your dev branch (using with YAML or a classic build) - that does not produce release notes
• This is consumed by a Classic Release

If this is the case, then what you are experiencing is the designed behaviour.

The logic in this task for finding associated builds for Classic Releases is my own, as Microsoft provides no suitable APIs. This is unlike for YAML pipelines, both single and multistage, where there is a set of API calls to find the WS and CS changes between successful pipeline runs on the same branch. So I had to create my own logic, which is:

1. Find the artifact version being consumed by the release
2. Goes back through previous releases until it find the last time there was a successful release, get the build number of the artefact used that time - if none is found use the first build of the artefact type
3. Get the details of the CS/WI for all the past build listed on step 2

The good news is there is feature to address the problem you have. You need to add the overrideBuildReleaseId and set it to the ID of oldest release you wish to consider i.e. only consider releases after this time. With this set the logic become

1. Find the artifact version being consumed by the release
2. Goes back through previous releases until it find the last time there was a successful release Or until you get the overrideBuildReleaseId) get the build number of the artefact used that time - if none is found use the build of the artefact type used by the overrideBuildReleaseId` release
3. Get the details of the CS/WI for all the past build listed on step 2

Hopefully that will sort your problem.

Also worth considering is

1. Run the release notes task in the build that is run when a PR is merged to generate the notes for that PR
2. Publish this to a wiki

See this video on how we use these tasks

[astanley]

Thank you for the response!

You are correct - using Classic Release Pipeline. My objective is to generate release notes for our QA team - they want deployments to their QA env 2x per week, so I thought it would be ideal to schedule the release pipeline to run on those days, and generate a release notes summary containing info about all builds since the last QA deployment.

However, to your point, maybe I should move this logic into my build pipeline? My concern with that is - there could be 10-20 builds between QA deployments, so how would I avoid generating 10-20 separate "release notes" documents (I just want 1 for deployment day).

I apologize for the ignorance but I just don't understand what value I'm supposed to put in for overrideBuildReleaseId field.

1. Is it a release ID, from my classic release pipeline? As mentioned above my issue is happening on the first run of my release. So I don't have a successful release Id from my release pipeline to provide. Are you suggesting I put in the releaseId of a past failed run?
2. Is it a build ID from my CI pipelines? I entered a build ID= 111901 (that is a build that ran last week on the _myFooBarBuildPipeline artifact) but unfortunately experienced the exact same behavior: my release tried to process all of my builds +1000 - it appeared to ignored the buildID value I entered.

2024-05-23T11:43:12.6323966Z Creating the credential handler from the OAUTH token
2024-05-23T11:43:12.8586541Z Getting the current release details
2024-05-23T11:43:12.9527914Z Show associated items for primary artifact only is set to true
2024-05-23T11:43:12.9528179Z Getting the Environment Id
2024-05-23T11:43:12.9528352Z Identified [build listener ] as having id [13]
2024-05-23T11:43:12.9528898Z Using the override for the last successful release of ID '111901'
2024-05-23T11:43:12.9529121Z Finding successful deployments
2024-05-23T11:43:13.0253665Z Getting all artifacts in the current release...
2024-05-23T11:43:13.0255437Z Found 1 artifacts for current release
2024-05-23T11:43:13.0256179Z Skipping fetching artifact in the most recent successful release as there isn't one.
2024-05-23T11:43:13.0256572Z Looking at artifact [_myFooBarBuildPipeline]
2024-05-23T11:43:13.0257408Z Artifact type [Build]
2024-05-23T11:43:13.0258150Z Build Definition ID [1234]
2024-05-23T11:43:13.0258889Z Build Number: [20240523.37]
2024-05-23T11:43:13.0259630Z Is Primary: [true]
2024-05-23T11:43:13.0260426Z Looking for the [_myFooBarBuildPipeline] in the most recent successful release [Initial Deployment]
2024-05-23T11:43:13.0261122Z Found artifact [_myFooBarBuildPipeline] with build number [20240523.37] in release [Initial Deployment]
2024-05-23T11:43:13.0261774Z This is the first release so checking what commits and workitems are associated with artifacts
2024-05-23T11:43:13.7432844Z Getting the details of build 112376
2024-05-23T11:43:13.9768912Z Getting the details of build 112374
2024-05-23T11:43:14.1697365Z Getting the details of build 112372
...
continue until OOM ...

[rfennell]

However, to your point, maybe I should move this logic into my build pipeline? My concern with that is - there could be 10-20 builds between QA deployments, so how would I avoid generating 10-20 separate "release notes" documents (I just want 1 for deployment day).

You could put the generate release notes task in the CD build in a YAML stage such that it is only run when the PR is merged to the trunk (dev or main). So the release notes are generated as the PR is completed, not on each build of the PR branch

To find the overrideBuildReleaseId, look at the list of release e.g.

Pick the one that you want as 'the oldest to consider' and click on it

You can see the ReleaseID in the URL, use this ID as the overrideBuildReleaseId in this case 2856

[astanley]

Thank you again for your attention on this matter. Today I moved my logic into my CI stage and used your suggestion of publishing to a wiki as a way of assembling my completed release notes.

1. My build pipeline runs the generate release notes extension to produce release notes for that build
2. My delivery pipeline combines that with release info and publishes both together as a wiki page

On behalf of the community, I greatly appreciate the effort you put into creating this extension and the support you give to all of us who are using it. Thank you again.