I think this might be a limitation of the API call that is being made, as it compared between simiple numeric releases, ignoring and rerelease complexities. I need to investigate

@rfennell I did the following test:

1. Cloned pipeline and re-ran release.
2. Run 1: Release = Release 1, Compare = Release 1, changes none.
3. Run 2: Release = Release 2, Compare = Release 1
4. Re-Run 2: Release = Release 2, Compare = Release 2

In step 1, should the Compare not be "None" and in step 4 be the last successful, but itself, i.e. "Release 1"? When it compares itself, there will be no differences.

1. Cloned pipeline and re-ran release.
2. Run 1: Release = Release 1, Compare = Release 1, changes none. - I would expect all wi/cs associated with the trigger build (this is new feature), the detailed logs show a special route has been taken
3. Run 2: Release = Release 2, Compare = Release 1 - Normal behavior
4. Re-Run 2: Release = Release 2, Compare = Release 2 - this is the problem, I need to look into this this, but it won't be straight away

I think the question is how is the task meant to know that step 4 (above) is really step 3.

It just looks for the last good release to compare against, and the step 3 one was good.

Any thoughts, how can we signal that step 4 is a redeploy?

@rfennell is there any way that the task can compare itself with the most recent successful build?

For example, release 31 compared itself with release 30. Release 30 compared itself with release 29, which was failed in post=deploy approvals.

I'm thinking aloud ... if we can configure the task to compare itself with the last successful release, for example Release 30 would compare itself with Release 26, we can fail a release, before re-deploying to fix this #440 issue. A bonus would be that the release notes would show the same results as what we see in the release summary when we manually compare with the last successful release.

Thoughts?

Yes, I think that is the only way

I think the task needs to check that this release does match the last successful release's artifacts. if it does in your example run the compare for 30 > 26 as opposed to 31 >30

Think that works?

@rfennell, sorry, my image is adding confusion. Ignore release 31 at the top. When Release 30 runs, it compares itself with Release 29 (which was failed in post-approval) according to the release notes. This is default behavior, even for the release summary view, so I would leave it "by default".

It would, however, be "cool" if we could configure the task not to process default behavior, but to compare itself with the most recent successful release. So, if we set this option, release notes would show that Release 31 compared itself with Release 26.

This behavior would unblock a few branching and release reporting issues we 're experiencing.

@rfennell if we could take it one step further. If configured to NON-DEFAULT, release 30 looks for the last successful release (other than itself), which is 26. When Release 31 runs it finds 30. When release 31 is re-deployed, it still looks for the last (other than itself) successful release, which is 30.

Seems reasonable, I will have a look

Checked the code, it should do the compare against the last successful release. If you run with system.debug=true it lists the last successful release, seems Ok from my tests

@rfennell you're correct. release summary, by default, compares with the previous release, even if failed. Your extension skips the failed releases 👍 I'm stoked and cannot wait to go back to the office tomorrow :) That means the only thing that is still an issue is the re-deploy, which compares the release with itself.

So my bug is good !

I won't fix it then, just the rerun issue and I have plan for that

@rfennell Test was successful. I failed 3 PR and 3 releases, then ran another release and the extension compared Current to Current - 6. Spot on!

In terms of a re-deploy a colleague had a great idea. How about the task skips release notes processing if Release.AttemptNumber > 1?

@wpschaub been a while but I have been thinking on this one.

• On the Release.AttemptNumber > 1 option where you thinking output a message somewhere?
• I was looking at trying to detect of a release was off the same artifacts as the previous one and using the changes from the previous release, but this is confusing.

I like tracking the Release.AttemptNumber number , but not sure what to do with it.

@rfennell I was thinking of allowing user to decide whether to re-run the release note generation if ReleaseAttemptNumber>1. By default I would not re-generate release notes, instead place a warning in the log that release notes were not regenerated due to the release being re-deployed.

That sounds like I need both, if we are a re-run then need to go back and get the old artifact number for the checks

Give 2..9.6 a try, it has a new advanced option that will skip generation of release notes on a re-deploy (of the stage the task is in). It completes with a 'pass with warnings'

The default is the old behavior, so it is a non-breaking change

Does that work for you?

Perfect, thank you! Blog - https://willys-cave.ghost.io/skip-release-notes-when-re-deploying-a-release/

@rfennell It sounds like you were attempting to find a way to compare to latest successful deployment (not the current) when redeploying. Did you determine that this wasn't going to be possible?

Sometimes if I don't like what was in the notes, or a work item gets missed, I'd like to go back and regenerate the release notes. Since redeploying won't recreate the notes, and since DevOps won't let you delete a release once it is completed, I don't really have any options if something went wrong.

@rfennell It sounds like you were attempting to find a way to compare to latest successful deployment (not the current) when redeploying. Did you determine that this wasn't going to be possible?

Sometimes if I don't like what was in the notes, or a work item gets missed, I'd like to go back and regenerate the release notes. Since redeploying won't recreate the notes, and since DevOps won't let you delete a release once it is completed, I don't really have any options if something went wrong.

@rfennell Any tips for situations like this? The main issue is that DevOps doesn't let you delete your last release. Still trying to figure out how I could regenerate the correct notes.

The only option I have found is to use the command line test harness I recently wrote and inject the values for the release you wish to re-run.

However even this is problemic if the release ran to completion as the task looks for the last success release to compare against, less if an issue if using multistage YAML.