The compareReleaseDetails becomes the same as releaseDetails when manually retrigger the deployment (additional: empty workitems issue)

[LouisSung]

Is your feature request related to a problem? Please describe.
I am now using the XplatGenerateReleaseNotes:v3.x to generate report, with Option 1: Generate notes since the last successful release.
However, I soonly face a problem that when I want to change the note template by Edit release, change the template format, and Deploy, the output content gets changed.

This might happens due to the mechanism to find last successful release doesn't exclude the release itself.
For example, in my Logs > Deployment attempt #1 for the second release:

# Notes for release Foo  
**Release Number**: Foo-2  
**Compared Release Number**: Foo-1  

in Deployment attempt #2, it becomes:

# Notes for release Foo  
**Release Number**: Foo-2  
**Compared Release Number**: Foo-1  <!--compare to the release itself because it just becomes successful-->

Describe the solution you'd like
After some quick survey, I found that someone has already mention this issue in #727 .
However, it was treated as running the stage at the first time, but not sure if the same issue for different attempts happened because it's a bug, an undefined behavior, or by design?

I think it might be an undefined behavior because releases are usually triggered automatically; however, it's somehow not intuitive if the result cannot be reproduced for different attempts within the same release.

It might not be that easy to change the logic for function getLastSuccessfulBuildByStage, but I expect it can realize that it's under different attempt instead of other situations like the first release.

Thank you :)

[rfennell]

But it is true to say that all the design is based about a build or release being run once, everything else is a edge case.

I need to have a bit of a think about what I can do to address your points.

[rfennell]

I have had a bit of think about this, the key fact is that the Microsoft release API will always look for the last successful release to the current stage for it's comparison. When you see 'deployment attempt 1, 2' etc. the compare will always compare against the first successful release to the stage, as you have noted.

I think adding logic to getLastSuccessfulBuildByStage to allow it to skip back past previously completed stage eployments would be confusing when, though this can be an issue while creating new pipelines/templates, it is not usually an issue for production usage.

If you are struggling to develop templates, can I suggest my command line tester, it is the tool use for all my template development

[LouisSung]

Sorry for the late reply due to missing the email notification _(:3

OK, just to make sure things are by designed.
What confuses us is the the same artifact generates different report (both different releases or attempts), but somehow it's the Azure DevOps's concept (based on stage instead of artifact or commit)

I'll close this issue, thanks.

[LouisSung]

BTW, just for sharing so I am not creating a new issue if not needed

Recently, we solve an issue for getting the workItems and relatedWorkItems as EMPTY Arrays (i.e., both get [] using dump syntax in template like {{{json workItems}}}).

By checking the implementation for acquiring an access token (getSystemAccessToken()), and override it with our own PAT (via overridePat), which can get the correct workItems, we can confirm that there exists some permission issues.

We finally find out that the organization setting Limit job authorization scope to current project for release pipelines (and/or the no-release one) should be disabled in order for the API to fetch workItems with the generated OAuth token.
// Refer the Job authorization scope (document by Microsoft) for more info.

I haven't seem this problem be documented or raised as an issue (or I just miss one?)
It takes days to find it out (e.g., make sure it's not because we set the PAT with wrong permission to our on-premise agent), maybe it can be mentioned somewhere (e.g., Readme?)

[LouisSung]

Here is the screenshot for the setting, it's ENABLED by default (this is an organization I just newly create)
(These settings are available by the organization (for all projects) or by the (single) project.)

/** UPDATED: Enable by default for new organizations and projects since May 2020 (announcement by Microsoft) */

The forth one should be DISABLED for the plugin XplatGenerateReleaseNotes to get the workItems in the release pipelines, whereas the third one for non-release pipelines

[LouisSung]

Reopen this issue for a few days for the empty workitems issue to be seeable, feel free to close it as needed (e.g., after readme updated)

[rfennell]

Thanks you for the feedback, I will get the documentation updated.