Get-BuildVariable: inconsistent commit message detection

[peppekerstens]

Build environment
Azure Devops

Tested
PS5.1/PS6core
build stage

Issue
the commit message detection code (

BuildHelpers/BuildHelpers/Public/Get-BuildVariable.ps1

Line 154 in 303eebe

$CommitMessage = switch ($Environment.Name)

) fails on detecting 'BUILD_SOURCEVERSIONMESSAGE'

root cause
After testing, the root cause seems to be two-fold:
Cause 1:

1. 'SYSTEM_DEFAULTWORKINGDIRECTORY' exists in both the BUILD and RELEASE stages of Azure DevOps. In both cases the default value are the 'artifacts' directories of the used agents (d:\a\r1\a when using hosted agents). So they are directory paths(!)
2. Somehow, PS does not obey the order of the 'switch' command anymore; it 'hits' on 'SYSTEM_DEFAULTWORKINGDIRECTORY' instead of 'BUILD_SOURCEVERSIONMESSAGE'. This is a PS 'thing' and beyond the scope of this issue.

Cause 2:
The detection does not obey the provided path parameter. I will create separate issue (#110) for this.

solution
The simplest solution is to use 'AGENT_RELEASEDIRECTORY' instead of 'SYSTEM_DEFAULTWORKINGDIRECTORY'.

[FISHMANPET]

This one is a little more interesting. I don't have a release pipeline or a hosted agent to play around with. I understand the problem in #110 and how that's manifesting here as well where we're grabbing the wrong directory regardeless. I'll take a look at this as well and at the very least use AGENT_RELEASEDIRECTORY instead of SYSTEM_DEFAULTWORKINGDIRECTORY.

Do you think specifying the Path to Set-BuildEnvironment is having impact here, or should have any impact?

[FISHMANPET]

So looking at a MS hosted YAML pipeline, I don't have AGENT_RELEASEDIRECTORY in the environment, so that's not a universal directory, but as I said in the other issue that's supposed to be a commit hash not a directory anyway. Also looking at my pipeline, SYSTEM_DEFAULTWORKINGDIRECTORY is D:\a\1\s and I have BUILD_ARTIFACTSTAGINGDIRECTORY, BUILD_STAGINGDIRECTORY, and SYSTEM_ARTIFACTSDIRECTORY, all of which point to D:\a\1\a. So maybe that's a difference between a YAML and a classic pipeline?

So I think what I described in the other issue will take care of Part 1 of your Case 1. Part 2 is a little trickier. I think what's happening isn't that order is being obeyed, but when you pass a collection into a switch statement it checks every item in order. So If you have both SYSTEM_DEFAULTWORKINGDIRECTORY and BUILD_SOURCEVERSIONMESSAGE in environment, what happens is first the switch catches on BUILD_SOURCEVERSIONMESSAGE and properly finds the message, then it catches again on SYSTEM_DEFAULTWORKINGDIRECTORY and since that's bugged it fails.

I may have to reevaluate what I'm doing here because I hadn't though hard enough about it, but using switch like this only works when exactly 1 of the environment variables in the switch statement is in your environment. Using 2 that may be in the environment can make things weird and non-determinant, though i'll have to do some testing in my branch and my test pipeline to verify that behavior.

Certainly it makes me thinks there should be some more tests written to try and catch some of these edge cases as well

[peppekerstens]

Currently, within the Azure DevOps interface, there a two pipelines; 'build' and 'release'.

I am able to use YAML for the 'build' section of the pipeline.
Documentation hints towards the fact that you can also use YAML for release. I however, have no direct interface to create/use a YAML file for the release section of Azure Devops.

Looking at your remarks, the use of YAML and returned environment var's, I tend to assume that you are testing/running things in the 'build' stage/environment of Azure DevOps.

Create a dummy release, request the env: you'll notice that there are other variables populated in the env:

Like AGENT_RELEASEDIRECTORY. Everything with BUILD_ is absend... :)

Looking at the documentation there is a hint that this is 'classic' functionality.

Looking at this, the 'modern way' seems to be (1) using only build and (2) using YAML. Which is (also) covered/solved by current code.

So it is not a mistake; it is on purpose. Using AGENT_RELEASEDIRECTORY makes it unique for release. There is no variable available for the Git hash so we do need that path again... :)