How to set PowerShell switch parameter from TeamCity build configuration

Question

I have a PowerShell script with the switch (boolean) parameter that I want to call from the TeamCity build phase.

I want the switch value (true / false) to be set according to the TeamCity build parameter, configuration parameter.

So something like this:

And in the PowerShell build step:

But that does not work.

I get this error

[14:27:01][Step 1/1] Cannot process argument transformation on parameter 'preRelease'. Cannot [14:27:01][Step 1/1] convert value "System.String" to type [14:27:01][Step 1/1] "System.Management.Automation.SwitchParameter". Boolean parameters accept only [14:27:01][Step 1/1] Boolean values and numbers, such as $True, $False, 1 or 0. 

As you can see, PowerShell seems to insist on interpreting the parameter as a string.

I have tried many options for writing a script argument. None of these works:

 -preRelease:%IncludePreRelease% -preRelease:([boolean]%IncludePreRelease%) -preRelease:([System.Convert]::ToBoolean(%IncludePreRelease%)) 

Answer 1

This is an old question, but if you are still looking for an answer, I managed to get it to work.

The main trick is that you should not use a colon between the parameter name and value, as it would be with PowerShell (I know, confusing ...).

It seems that TeamCity calls the script in a different way and passes the parameters as a string.

So, in your example, the following should work: -preRelease $% IncludePreRelease%

Note: I added a dollar sign in front of the TeamCity variable to change "true" to "$ true"

Let me know if this works for you.

Thanks!

Answer 2

No, it still won’t work. It seems that TC will always treat the value as a string no matter what. Maybe the answer was from the TC version that allowed this, but in the latest version this is not.

Without a colon:

 [16:18:37]Step 1/6: Migrate Up (Powershell) [16:18:37][Step 1/6] PowerShell Executable: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe [16:18:37][Step 1/6] PowerShell arguments: [-NonInteractive, -ExecutionPolicy, ByPass, -File, C:\BuildAgent\work\f2797fec10821a01\data\Migration\MigrateUp.ps1, "data\change scripts", DB, xxxxxxx, sa, *******, -NoExec, $false] [16:18:37][Step 1/6] C:\BuildAgent\work\f2797fec10821a01\data\Migration\MigrateUp.ps1 : A positional parameter cannot be found that accepts argument '$false'. 

With a colon:

  [16:18:37]Step 2/6: Migrate Up (Powershell) [16:18:37][Step 2/6] PowerShell Executable: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe [16:18:37][Step 2/6] PowerShell arguments: [-NonInteractive, -ExecutionPolicy, ByPass, -File, C:\BuildAgent\work\f2797fec10821a01\data\Migration\MigrateUp.ps1, "data\change scripts", DB, xxxxxx, sa, *******, -NoExec:$false] [16:18:37][Step 2/6] C:\BuildAgent\work\f2797fec10821a01\data\Migration\MigrateUp.ps1 : Cannot process argument transformation on parameter 'NoExec'. Cannot convert value "System.String" to type "System.Management.Automation.SwitchParameter". Boolean parameters accept only Boolean values and numbers, such as $True, $False, 1 or 0. 

Removing [switch] also does not work, since any value you give it will not be treated as a logical one, but rather a string assigned to a logical one - and therefore all logical operations will be $true .

In other words, everything you submit will look like this:

• 0 => '0'
• 1 => '1'
• $ false => '$ false'
• $ true => '$ true'

(none of them are == $false , but they are all equivalent to $ true)

I have no idea how to get TC to accept booleans! Best of all, I could assume that the argument was a string and use System.Convert.ToBoolean () inside my script ...

Answer 3

According to the Microsoft.Net documentation for Convert.ToBoolean, the value passed to the method should be:

For a successful conversion to occur, the value parameter must be either Boolean.TrueString, a constant whose value is True, Boolean.FalseString, a constant whose value is False, or it must be zero. When comparing values ​​with Boolean.TrueString and Boolean.FalseString, the method ignores case, as well as leading and space characters.

If you change the value of the TeamCity IncludePreRelease variable to " True " or " False " (without quotes), then it must correctly convert.

Answer 4

Make the switch transfer at all depending on the configuration parameter:

• When creating the configuration parameter, select the checkbox.
• In "Checked value" put "-preRelease".
• Leave the Unchecked Value field blank.
• Just add "% IncludePreRelease%" to your script arguments. When this parameter is checked, it will pass "-preRelease" (= true), and when not, it will be omitted (= false).

This worked for me using TeamCity 10.0.4.

Answer 5

I know this is a late answer, but my colleague just came across the same problem and found this question.

If we forget about TC for a minute, if you want to execute the same command from the cmd console (not powershell ), then the exact command could be:

powershell.exe -File script.ps1 -preRelease

This command sets the switch to True. The important thing is that the command is first parsed by the shell ( cmd ).

Since the shell is cmd , the command line code on the command line will not be executed.

For example:

powershell -File script.ps1 -preRelase:"([System.Convert]::ToBoolean(%IncludePreRelease%))"

after the first cmd parsing, it ends:

powershell -File script.ps1 -preRelase:"([System.Convert]::ToBoolean(True))"

so the preRelease flag preRelease set to the entire line, which gives you exactly

 Cannot process argument transformation on parameter 'preRelease'. Cannot convert value "System.String" to type "System.Management.Automation.SwitchParameter" 

Based on the documentation , when using -File you either pass switch options or not. There seems to be no way to pass True or False .

To make it work, change from -Command to -Command like this:

powershell -Command .\script.ps1 -preRelease:$%IncludePreRelease%

Now back to TeamCity. Teamcity does not seem to support -Comand, as above. They support it by dumping your entire script into the command line as a script block, which can lead to very interesting errors.

The solution is to change the Script to Source and inside the contents of the script add

.\script.ps1 -preRelease:$%env.IncludePreRelease%