Closed joranm closed 5 years ago
confirmed
workaround; I tried using version 1.1.4 of BuildHelpers. This version works. Looking at the code I can only see this difference within Get-BuildVariable(s).ps1;
'BUILD_SOURCEVERSION' {
if($WeCanGit)
{
Invoke-Git @IGParams -Arguments "log --format=%B -n 1 $( (Get-Item -Path "ENV:$_").Value )"
break
} # VSTS (https://www.visualstudio.com/en-us/docs/build/define/variables#)
}
'SYSTEM_TEAMPROJECT' {
if($WeCanGit)
{
Invoke-Git @IGParams -Arguments "log --format=%B -n 1 $( (Get-Item -Path "ENV:$_").Value )"
break
} # VSTS (https://www.visualstudio.com/en-us/docs/build/define/variables#)
}
I did not try/test later versions (used 1.1.4 as a fixed version in builds until now)
As of yet, it is not clear to me why the error pops up;
I get this same error on a hosted Windows 2016 agent:
Invoke-Git : Cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'Message'. Specified
method is not supported.
At C:\Users\VssAdministrator\Documents\WindowsPowerShell\Modules\BuildHelpers\2.0.7\Public\Get-BuildVariable.ps1:180
char:17
+ ... Invoke-Git @IGParams -Arguments "log --format=%B -n 1 $( ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Invoke-Git], ParameterBindingException
+ FullyQualifiedErrorId : CannotConvertArgument,Invoke-Git
I DO NOT get this error when the same build script is run on the hosted macos agent.
The error is with the Invoke-Git from the SYSTEM_TEAMPROJECT environment variable. The git command gives an error and Line 149 of Invoke-Git has it sending an array/object to Write-Error, which is invalid. This results in the "Cannot convert 'System.Object[]' to the type 'System.String'" exception.
The -split on Line 126 converts the String to a String[], which would also throw an error when written out, then the "Where-Object {$_}" on the same line converts it to an Object[].
I think changing line 149 to allow arrays will fix this: $stderr | Write-Error
The git error being thrown is a separate issue, here's the error:
fatal: ambiguous argument 'TestProject': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git
The command Invoke-Git runs which generates the error is this: git.exe log --format=%B -n 1 TestProject
I should have looked at open PRs. PR #101 fixes the "Cannot convert" error. As a workaround to the git error I edited line 184 of Get-BuildVariable to remove the environment variable output: Invoke-Git @IGParams -Arguments "log --format=%B -n 1"
I have a maybe related issue, running on a VSTS hosted VS2017 agent with GitHub Enterprise (rather than regular GitHub) as a source, and I get the following error from Set-BuildEnvironment
with no parameters
Invoke-Git : fatal: ambiguous argument 'RepoName': unknown revision or path not in the working tree.
At C:\Program Files\WindowsPowerShell\Modules\BuildHelpers\2.0.8\Public\Get-BuildVariable.ps1:184 char:17
+ ... Invoke-Git @IGParams -Arguments "log --format=%B -n 1 $( ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Invoke-Git
It's executing line 184 which tells me it's in the 'SYSTEMTEAMPROJECT' switch. I'm not sure what the Environment is supposed to represent at that point, `"$( (Get-Item -Path "ENV:$").Value )"run on my local console is just the entire Environment, so I'm not sure what it's supposed to represent in this switch. It's accurately showing my Git Repo name in the ambiguous argument message. I know that's some kind of Git message but I'm not exactly sure what could be different here vs running a hosted VSTS agent with public Github, which I've been able to do successfully with the same
Set-BuildEnvironment` command
Nope I just built a project from public github and the same issue above happened, I'm going to open a new issue on that since I think it's slightly different from this one?
Platform/Agent Azure DevOps/Hosted VS2017
Executing (Get-BuildVariable).BuildSystem
Results in