We’ve upgraded from Continua 1.6 to 1.7.1.84 and all our Powershell actions that were passing in script arguments broke because Continua resolves the variables and passes the values wrapped in parentheses.
For ex, $Source.SVN_Trunk$\Documentation\MDwiki got passed in as (D:\CIWS\Ws\196680\Source\SaaSToolset_Trunk\Documentation\MDwiki) which causes Powershell to throw errors about arguments with no values.
We can work around it by wrapping all our variables in double-quotes, but that’s quite a lot of scripts and actions to update. Why were parentheses chosen instead of double quotes?
Hi Miruna,
Some users were having issues passing in arguments which were not strings, such as arrays. If we wrapped all the argument in double quotes these would be ignored . Other users were having issues with character escaping within quotes .
We spent some time looking into solutions which would work for these cases. This issue is complicated because we need to call the script using “invoke-expression -Command” so we can get an exit code and know if the script has failed. We found that this works best if strings were sent to PowerShell as named arguments surrounded in single quotes and other data types were wrapped in parenthesis.
In previous versions the field description stated that arguments should be surrounded in double quotes ‘The arguments to pass to your script. e.g. -param1 “value 1” -param2 “value 2”’
We have now changed this description to “The arguments to pass to your script. e.g. -param1 ‘value 1’ -param2 ‘value 2’ ‘unnamed argument’”. Now any arguments which are wrapped in single or double quotes are converted to single quotes and are sent to PowerShell as named arguments. Any arguments not wrapped in quotes are surrounded in parenthesis.
Sorry that you need to change all PowerShell actions to deal with this changes, but without quotes we cannot reliably determine whether the argument is a string or one of the other PowerShell data types. We plan to make it easier to make changes across all Continua projects in future.
That makes sense and it’s what I figured when I saw the note about fixing arrays in PowerShell in the release notes for one of the builds of 1.7. However, we were also using > to pipe the output to a file and I can’t quote that one. The exit code is great, but we also need the output for notification emails when builds fail.
Any plans to add logging the output to the PS Continua action? Or to split the action into one that runs PS scripts and one that can run arbitrary PS commands and would be less restrictive on param values? Or is the only workaround to call into a FinalBuilder script that runs Execute PowerShell which can save the output to a variable?
Hi Miruna,
The output of the PowerShell script is currently added to the build log, but we’ll also look into adding “a log output to file” option to the action.
Meanwhile, you can redirect the output of commands in your PowerShell script using the Out-File cmdlet e.g.
dir | Out-File C:\temp\dirOutput2.txtOr save a transcript of all commands in your script to a file using Start-Transcript and Stop-Transcript e.g.
Start-Transcript -path C:\temp\dirOutput.txt -append | out-nulldirStop-Transcript | out-nullOr store the output to a Continua variable using redirection and Custom Log Messages e.g.
$dirOutput = & dir 2>&1write-Host “@@continua[setVariable name=‘dirOutput’ value=’$dirOutput’]”