Enable Change log check during release and analyse step

[praveenkuttappan]

Change log check is disabled now due to issues we have noticed during last release. We need to make required fix and enable this before next release. Here are the two issues we have noticed last.

1. Preview release version is incorrectly parsed or formatted for no change log is found for the version
2. Unreleased change log header check should be done only for release build and not for manual build. Both analyze and release step should perform same set of checks.

One solution for issue #2 is as follows:

1. Create a new build time variable "Build.ForRelease" and this should be defaulted to true for any manually queued build. If build.forRelease is true then we should perform same set of checks during release and analyze step.
2. When build is queued manually and for not release purpose then this variable needs to be explicitly set to false.

Scott Beddall (@scbedd) Please let me know if I have missed any point.

Chidozie Ononiwu (@chidozieononiwu) : just FYI.

[chidozieononiwu]

1. The issue with preview version being formatted wrongly is fixed with https://github.com/Azure/azure-sdk-tools/pull/772/files

2. Why is this necessary? The intention is to run the Verify-ChangeLog on release only when there is an actual release approval. In which case you are already certain it is going out for release. in which case all you need to do is pass the ForRelease parameter when you call the template. Unless there is some other issue you intend to avoid I believe this should be sufficient.

[scbedd]

Why is this necessary? The intention is to run the Verify-ChangeLog on release only when there is an actual release approval.

You're absolutely correct, but we have changelog verification in our BUILD phase as well. What's currently happening is that the "Build" stage is SUCCEEDING prior to failing during the release. This is super confusing for the devs because the build stage (which INCLUDES verify-changelog) WAS GREEN!

[praveenkuttappan]

Our intention is to ensure that same check is performed during analyze and release for release build so if release is going to find any issue then it's better to find that in analyze phase

[chidozieononiwu]

Ok, I see what you mean. I will add the check to the verify-changelog.yml.

[chidozieononiwu]

I have a PR addressing this Azure/azure-sdk-tools#797

[weshaggard]

While I completely understand there is a little confusion between running the verify-changelog step as part of the build and as part of the release there are reasons for splitting the verification. We want to do as much verification as we can during the build/analyze phase to make sure folks are thinking about and at least have a place holder for the current active version. During release we want to verify that the change log is not empty and that the version entry is not marked as unreleased. We cannot do this step during the build/analyze step because we don't know if they plan to release a given package. Imagine a pipeline that has multiple packages and only a subset of packages are planning to release we cannot enforce the release criteria on the other packages.

So in our current system I don't think we can move all the validation into the build/analyze step. If we feel having it run it both build and release adds to confusion we could move all the validation to the release stage for a build we plan to do a release from, but we still want the verification in the build/analyze phase the rest of the time so people are setup for success during development.