-
-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removing 'path' parameter from 'git log' command #118
Removing 'path' parameter from 'git log' command #118
Conversation
@@ -160,21 +160,21 @@ function Get-BuildVariable { | |||
'CI_COMMIT_SHA' { | |||
if($WeCanGit) | |||
{ | |||
Invoke-Git @IGParams -Arguments "log --format=%B -n 1 $( (Get-Item -Path "ENV:$_").Value )" | |||
Invoke-Git @IGParams -Arguments "log --format=%B -n 1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So! In this section (getting commit message), the deleted bit is the commit sha. If you leave this off, AFAICT it will get the current commit. Potential corner case: Someone has been moving around in their build (checking out a different commit), but still want to refer to the commit message of the build's commit.
Do these lines ever error out for you? Maybe I'm grabbing a wrong environment variable? Intention in this section is to grab commit to do this: https://stackoverflow.com/a/3357357
@@ -186,21 +186,21 @@ function Get-BuildVariable { | |||
'SYSTEM_DEFAULTWORKINGDIRECTORY' { #Azure Pipelines, this will be triggered in the case of a classic release pipeline | |||
if($WeCanGit) | |||
{ | |||
(Invoke-Git @IGParams -Arguments "log --format=%B -n 1 $( (Get-Item -Path "ENV:$_").Value )").split([Environment]::NewLine,[System.StringSplitOptions]::RemoveEmptyEntries) -join " " | |||
(Invoke-Git @IGParams -Arguments "log --format=%B -n 1").split([Environment]::NewLine,[System.StringSplitOptions]::RemoveEmptyEntries) -join " " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this one is weird. It should be a commit sha, not a path, not sure what happened.
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 |
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.
If we use the Git Commit Id, things are much better:
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 If we leave |
…ECTORY' to 'BUILD_SOURCEVERSION'
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.