Closed raandree closed 5 years ago
Okay, added comments! Long story short, intention is to use an environment variable that indicates the current build's commit sha, and to get the commit message associated with that commit via this method.
As mentioned, you could imagine a hypothetical, perhaps ill-advised scenario where someone move around in their repo (to a different commit), and still wants to refer to the current commit message. Removing the git commit sha from the command in that case will AFAIK get the commit message for what they have checked out, rather than for the commit he build is running against
Let me double check, but yeah, we should totally scrap SYSTEM_DEFAULTWORKINGDIRECTORY
. Is there a commit sha environment variable we can point to instead of that?
Ok, got the point of that. But what happens using the path is actually this:
Like you do in your Init task, my build process sets the location to $ProjectRoot. Then getting the log with the path as an argument fails like that.
PS C:\BuildWorkerSetupFiles\_work\r2\a\CommonTasks CI\SourcesDirectory> git branch
* (HEAD detached at 417779a)
PS C:\BuildWorkerSetupFiles\_work\r2\a\CommonTasks CI\SourcesDirectory> git log -n 1 C:\BuildWorkerSetupFiles\_work\r2\a
fatal: C:\BuildWorkerSetupFiles\_work\r2\a: 'C:\BuildWorkerSetupFiles\_work\r2\a' is outside repository
If we use the Git Commit Id, things are much better:
PS C:\BuildWorkerSetupFiles\_work\r2\a\CommonTasks CI\SourcesDirectory> git log -n 1 417779a652535f229430e6289a229b85fba
f6b5f
commit 417779a652535f229430e6289a229b85fbaf6b5f (HEAD, origin/dev)
Author: Install <Install@contoso.com>
Date: Tue Sep 17 09:50:20 2019 +0530
Test Commit 2
For Azure Pipelines, according to Release variables and debugging there are two variables storing the Git Commit Id:
In AppVoyer the variable is the varialble 'APPVEYOR_REPO_COMMIT' but one can get the commit message from 'APPVEYOR_REPO_COMMIT_MESSAGE'.
I am not sure about all the other build systems that you support.
Perfect! So! The only case where that would be a path in the code is for SYSTEM_DEFAULTWORKINGDIRECTORY
.
If we leave $( (Get-Item -Path "ENV:$_").Value )
in each spot, and change SYSTEM_DEFAULTWORKINGDIRECTORY
to Build_SourceVersion
(it appears underscores are used in place of periods in environment variable names), then all of those cases should evaluate to variables that store a commit hash, rather than a path.
OK, changed the code to the previous state and replaced the variable 'SYSTEM_DEFAULTWORKINGDIRECTORY' with 'BUILD_SOURCEVERSION'.
Works for me, merging, thanks, and shooot forgot the conf started, sorry!
This fixes #109 and #110.
As far as I have understood the git documentation, the path parameter for 'git log' is more like a filter to get the last commit for a specific directory or file. So here the path is it used twice and the two values may contradict each other . The current path must be set to somewhere in the git repo anyway and then - if things are as expected - the path (SYSTEM_DEFAULTWORKINGDIRECTORY) shows to the same repo again. In my case, I am having more than one artifact to deal with and the path in SYSTEM_DEFAULTWORKINGDIRECTORY does not point to the repo. The repo is in a separate folder in SYSTEM_DEFAULTWORKINGDIRECTORY.
And if the commit message could not be retrieved, we get in in line 224 without the path.
I don't see any value in defining the path as it is done for the 'git log' calls. Please correct me if I am wrong.