-
-
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
Get-BuildVariables fails if git is aliased to hub.exe #80
Comments
RandomNoun7
changed the title
Set-BuildEnvironment fails if git is aliased to hub.exe
Get-BuildVariables fails if git is aliased to hub.exe
Nov 13, 2018
RandomNoun7
added a commit
to RandomNoun7/BuildHelpers
that referenced
this issue
Nov 13, 2018
[hub](https://github.com/github/hub) is a tool put out by git that adds commandline tools to help developers work with github from the commandline in a more natural way. It is designed to be used by aliasing git to hub.exe. Hub then handles the additional commands it knows how to implement, and transparently passes through any native git commands to git.exe. The Get-BuildVariable cmdlet does not account for the possibility that git might be aliased, and assumes that the output of Get-Command 'git' can authoritatively be treated as either returning a Path to git or determining that git is not installed on a system. This change switches the method of determining the path to git over to looking at each path in the $env:PATH variable, and returning the path to the first instance of git.exe that it finds. This should be the same method used by Get-Command, and isn't fooled by the presence of aliases.
RandomNoun7
added a commit
to RandomNoun7/BuildHelpers
that referenced
this issue
Nov 13, 2018
[hub](https://github.com/github/hub) is a tool put out by git that adds commandline tools to help developers work with github from the commandline in a more natural way. It is designed to be used by aliasing git to hub.exe. Hub then handles the additional commands it knows how to implement, and transparently passes through any native git commands to git.exe. The Get-BuildVariable cmdlet does not account for the possibility that git might be aliased, and assumes that the output of Get-Command 'git' can authoritatively be treated as either returning a Path to git or determining that git is not installed on a system. Unfortunately if git is aliased to hub.exe then the result of Get-Command is not an object of type `System.Management.Automation.ApplicationInfo` that has a `Path` property but an object of type `System.Management.Automation.AliasInfo` which does not contain a path either to git or to the executable it's been aliased to. One possible strategy would be to find that git has been alaised and find the path to executable that it has been aliased to, but this seems less than ideal since the third party binary is not what this module really wants to execute, and this module will only ever need the capabilities of the native git.exe, not the extended capabilities of hub. This change switches the method of determining the path to git over to looking at each path in the $env:PATH variable, and returning the path to the first instance of git.exe that it finds. This should be the same method used by Get-Command, and isn't fooled by the presence of aliases. This change should be a fix for RamblingCookieMonster#80
RandomNoun7
added a commit
to RandomNoun7/BuildHelpers
that referenced
this issue
Nov 13, 2018
[hub](https://github.com/github/hub) is a tool put out by git that adds commandline tools to help developers work with github from the commandline in a more natural way. It is designed to be used by aliasing git to hub.exe. Hub then handles the additional commands it knows how to implement, and transparently passes through any native git commands to git.exe. The Get-BuildVariable cmdlet does not account for the possibility that git might be aliased, and assumes that the output of Get-Command 'git' can authoritatively be treated as either returning a Path to git or determining that git is not installed on a system. Unfortunately if git is aliased to hub.exe then the result of Get-Command is not an object of type `System.Management.Automation.ApplicationInfo` that has a `Path` property but an object of type `System.Management.Automation.AliasInfo` which does not contain a path either to git or to the executable it's been aliased to. One possible strategy would be to find that git has been alaised and find the path to executable that it has been aliased to, but this seems less than ideal since the third party binary is not what this module really wants to execute, and this module will only ever need the capabilities of the native git.exe, not the extended capabilities of hub. This change switches the method of determining the path to git over to looking at each path in the $env:PATH variable, and returning the path to the first instance of git.exe that it finds. This should be the same method used by Get-Command, and isn't fooled by the presence of aliases. This change should be a fix for RamblingCookieMonster#80
RandomNoun7
added a commit
to RandomNoun7/BuildHelpers
that referenced
this issue
Nov 13, 2018
[hub](https://github.com/github/hub) is a tool put out by git that adds commandline tools to help developers work with github from the commandline in a more natural way. It is designed to be used by aliasing git to hub.exe. Hub then handles the additional commands it knows how to implement, and transparently passes through any native git commands to git.exe. The Get-BuildVariable cmdlet does not account for the possibility that git might be aliased, and assumes that the output of Get-Command 'git' can authoritatively be treated as either returning a Path to git or determining that git is not installed on a system. Unfortunately if git is aliased to hub.exe then the result of Get-Command is not an object of type `System.Management.Automation.ApplicationInfo` that has a `Path` property but an object of type `System.Management.Automation.AliasInfo` which does not contain a path either to git or to the executable it's been aliased to. One possible strategy would be to find that git has been alaised and find the path to executable that it has been aliased to, but this seems less than ideal since the third party binary is not what this module really wants to execute, and this module will only ever need the capabilities of the native git.exe, not the extended capabilities of hub. This change switches the method of determining the path to git over to looking at each path in the $env:PATH variable, and returning the path to the first instance of git.exe that it finds. This should be the same method used by Get-Command, and isn't fooled by the presence of aliases. This change should be a fix for RamblingCookieMonster#80
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
hub is a tool put out by github that adds capabilities to git. The recommended way to use hub is to alias git to hub.exe, so that it can transparently handle the things it knows how to handle, and just pass on any commands that it doesn't.
When executing Get-BuildVariables cmdlet the line that attempts to find the path to git.exe uses the Get-Command cmdlet. This will not work in cases where git is aliased as no Path property is returned.
A different approach that either finds git.exe directly by looking at paths in the PATH variable, or one that accepts an alias, may be needed to support this scenario on workstations.
While this error should rarely or never be encountered on the build servers this module is intended to be used on, it is also used on developer workstations where this error can reasonable be expected crop up once in a while.
The text was updated successfully, but these errors were encountered: