Properly determine Git commit message in Azure Pipelines

[FISHMANPET]

There was a regression introduced in #89 that this will fix, which has been reported in #100 (Fixes #100)

The code in that pull changed the switch to get the commit message from BUILD_SOURCEVERSION to SYSTEM_TEAMPROJECT. BUILD_SOURCEVERSION was the git commit ID of the change, which resulted in calling git log --format=%B -n 1 <commitid> which if you run in your local git repo, will return the most recent commit message.

It was changed to SYSTEM_TEAMPROJECT which is the name of the project, which results in a git command of git log --format=%B -n 1 <projectname>.

Generally speaking, git log is fairly flexible, and so it turns out in the first case the parameters being used are git log [<options>] [<revision range>] and in the second it ends up being git log [<options>] [[--] <path>…​]

The problem is that the name of the project is neither a path or commit ID, it's... the project name. Now for a project like BuildHelpers, where there is a folder in the root of the project with the same name as the Project (project name BuildHelpers has a BuildHelpers directory in the root) it ends up basically working, because most changes will be in that directory, and the point of the <path> parameter to git log is to explain changes to files in <path>. If you make changes only outside of that project folder, Set-BuildEnvironment will execute successfully, but it will end up getting the wrong commit message, because it's looking for the last commit message inside that folder, rather than the last commit for the repo.

But if your project doesn't have a folder name that matches the project name, you'll get an error from git log: ambiguous argument 'RepoName': unknown revision or path not in the working tree.

So it turns out one of the variables that Azure Pipelines has is BUILD_SOURCEVERSIONMESSAGE which is the commit message of the current build, so instead of using git to find it, I just used that variable.

The original impetus for #89 was to allow proper identification of Azure Pipelines in a classic release pipeline, which has a slightly different set of variables. Specifically it doesn't have BUILD_SOURCEVERSIONMESSAGE so I added a second case that I believe will work in a release pipeline, but I'd like @lipkau to confirm since it sounds like they're using release pipelines so they'll be able to verify this works.

Another change that @lipkau made was to push the BuildHelper variables back into Azure Pipelines, but Azure Pipelines variables can't have multiple lines (at least not without some finessing) so I ensure BHCommitMessage variable won't have any new lines.

Finally, in #89 there was discussion about renaming VSTS and, I bit the bullet and changed all references to VSTS to Azure Pipelines. Visual Studio Team Services isn't a thing anymore since September 2018, the cloud offering is called Azure Devops, and the on-prem version is called Azure Devops Server, but in both cases the product is much more than a build environment, and both use the name Azure Pipelines to describe their build environment, so I believe that's the appropriate name going forward. I also added some tags to the module definition to reflect that this works for AzureDevops Pipelines.

[FISHMANPET]

I've also setup a very rudimentary Azure Pipeline for this: https://dev.azure.com/fishmanpet/BuildHelpers/_build?definitionId=1

All it does is import the module and run it to ensure it doesn't bomb out, though doing this wouldn't catch the issue this PR is trying to fix, because of the reasons described in my initial message.

[RamblingCookieMonster]

Awesome, thanks for helping out! I think I'll bump the major version for this, on the off chance anyone is doing any gate-keeping or logic that will be broken by the change to BuildSystem (which makes sense to change, for sure!)

Should be able to get this in the next day or two - thanks again!

[FISHMANPET]

ok I snuck one more name change in, my OCD was bothering me so I changed "Github Action" to "Github Actions" because the product name is plural, I also changed the tag names instead of adding new ones since BuildHelpers was the only project using "Github-Action" and the only build related project using "Action"

Feel free to reject those last two or let me know if you want a separate PR for them or something

[RamblingCookieMonster]

Works for me! Will merge this in, deploy when a few other PRs are merged in, with a major version bump - thanks again!