The default execution policy of PowerShell seems to be Restricted, meaning it won't run any script files (it is restricted to just an interactive command console). But the PowerShell plugin creates a temp file (e.g. "hudson3492366779710559401.ps1") with the script content from the Job's configuration and then attempts to run it through powershell.exe. How does this mesh with that default execution policy? One option is to liberalize the execution policy (e.g. Set-ExecutionPolicy Unrestricted), but that is rather loose, applying to any script file. Is this what everyone else is doing?

The PowerShell plugin fails for me unless I first execute 'Set-ExecutionPolicy remotesigned' in a PowerShell window. This is messy and also won't be adequate when Hudson runs as a service.

Wim wrote:

> The normal way would be to set your policy to RemoteSigned.

How do I do this please?

Could the plugin not do this when it invokes the Hudson generated script (e.g. PowerShell -ExecutionPolicy remotesigned hudson3492366779710559401.ps1) ?

good plugin, but it has a big downfall: no return value. Even if the build fails, Hudson doesn't seem to recognize it and says everything is fine. So I switched back to Batch-Scripts with a command like " powershell.exe "& 'script.ps1'" "

Hello folks,

I'm having issue with ExecutionPolicy too. I have opened up the Powershell console as the same user that is running the Hudson service and issued "Set-ExecutionPolicy unrestricted". However, I'm still getting the following when executing any Powershell command from the build step:

File C:\DOCUME~1\SVC_PR~1\LOCALS~1\Temp\hudson6647546035708680215.ps1 cannot be loaded because the execution of scripts is disabled on this system

How do I tell Hudson to always run Powershell scripts with ExecutionPolicy="Unrestricted" (or RemoteSigned, whatever)?

Thank you in advance!

-Jamie

Sorry if this is slightly off topic, but I'm also using a 64-bit Windows 7 and also getting the 32bit PowerShell :(

There was no Java installed when I installed Jenkins (perhaps my first mistake)

I've now installed both 32 and 64 bit JREs, but I cannot find a setting in Jenkins to tell it which to use.

Is replacing the JRE subfolder in Jenkins with the 64bit version of the JRE the right thing to do ?

I patched the plugin to make it bypass the execution policy (and fail when the script contains errors). The patch and an .hpi are attached to https://issues.jenkins-ci.org/browse/JENKINS-15890 It works for me, but it would be nice if a few other people would test this.

If you go to "Manage Jenkins" > "System Properties" and look for the 'java.vm.name' (this will say 64bit version if jenkins is running as x64. And 'os.arch' (Operating system architecture) will tell you the OS architecture. 

I wouldnt replace the JRE folder, I don't know what side efffects that may or may not have, or what other apps on your computer it may break.

Basically to make it use the 64bit version, you need to start java.exe 64bit version. So you need to adjust whatever you startup commands are to use the right JRE/JDK bin directory. 

I'm not sure what comes with the windows installable version of Jenkins these days, but early on it was the 32bit version. Its actually very easy to use the war version on windows, just download whichever version of java, and then download the war file, then startup jenkins on the command line using java -jar jenkins.war (setting whatever other parameters you would like to pass into it (see this page for more options https://wiki.jenkins-ci.org/display/JENKINS/Starting+and+Accessing+Jenkins )

So, if you: 

• Install perfered version of java
• Set it as JAVA_HOME system variable on windows (or use the full path to java.exe if you don't wan't it as a environment variable)
• Run the java -jar jenkins.war command to start it up (with whatever other start up options you want)
• Then install as windows service from within the jenkins 'Manage Jenkins' section

You should have Jenkins working on whatever java version you want. 

Once up and running, you can check if you are in a 32 bit shell like this:

• PowerShell run “Write $PSHome” and if you have a Wow64 directory in the path, you are in a 32 bit process
• In command shell run “echo %programfiles%” and if the program files directory has (x86) in it, you are in a 32 bit process

I have also found power shell output being cut off by the 'virtual console output size' in powershell. This command can adjust it, run this as the first line of you power shell script. 

Get$Host.UI.RawUI.BufferSize = New-Object Management.Automation.Host.Size (500, 25)

I've never had to run both 32bit and 64 bit process's, however I believe if you run Jenkins as x64, you should be able to run 32bit exe's by calling them directly (so you don't get their x64 equivalent). 

There is an obnoxious "bug" with this plugin. If I have an issue with my powershell script and fail to provide a required parameter, it will hang waiting for user input to provide the required parameter. The very trivial fix would be to execute powershell with the -noninteractive, which would cause this to be reported as an error and therefor fail my build with a meaningful error message rather than just hanging indefinitely with no suggestion as to what is going on.

Additionally, it should be possible to make it configurable (like the MSbuild plugin) to choose between 32 and 64 bit versions of powershell, which was an issue for a different part of my build process, which I worked around with a somewhat hack solution.

I have installed the plugin and am trying to create a variable as part of a powercli script, then access the value in a Windows Batch Command step.  I have tried lots of things, but can't seem to make this work.  Is it possible?

In 'Execute Windows Batch Command' task, I have this:

echo myY should show a value here : %myY%

Value doesn't show up.  Anyone see what I am doing wrong?

I have powershell version 3.0 installed and when I try to run a powershell command or script, i still get the same error.

& : File C:\windows\TEMP\hudson5041614610100256691.ps1 cannot be loaded 
because running scripts is disabled on this system.
& : File C:\windows\TEMP\hudson5041614610100256691.ps1 cannot be loaded  because running scripts is disabled on this system.

what is the workaround and Is this error addressed in version 3.0 ?

Error:  File C:\WINDOWS\TEMP\hudson2202497609195961964.ps1 cannot be loaded because running scripts is disabled on this system. 

I had already launched my Powershell and set the execution policy to RemoteSigned and still received this error.  Jenkins launches the x86 version of Powershell.  I suspected that I needed to launch the x86 version of Powershell and set the execution policy there too!   

Solution:  Launch the x86 version of Powershell (as Administrator) C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Powershell.exe  and set the execution policy there as well (set-executionpolicy RemoteSigned)

Hope this helps!

Current LastExitCode support is not full.

return command + "\r\nexit $LastExitCode";

better:

powershell -NoProfile -ExecutionPolicy unrestricted -Command "try{ & { .\make.ps1

If there is syntax error in .\make.ps1, 'if ($LASTEXITCODE)' part skipped, but powershell self exits with 1.

So I have V1.3 installed, but I still always get an exit code of 0 regardless of success or failure

Ah... my scripts are not in fact using LastExitCode. So something is wrong in this plugin.

I have the workaround of adding ;$LASTEXITCODE but who wants to do that when calling multiple scripts.

Help!

Is there an easy way to use the x64 PowerShell instance? It's using the x86 by default. It'd nice to have an option to change the engine.

Powershell plugin not supporting Credential object.But the windows powershell does.

How to rectify the below error.

\TEMP\hudson6249932248540013738.ps1'"

Rename-Item : Cannot retrieve the dynamic parameters for the cmdlet. The provid
er does not support the use of credentials. Perform the operation again without
specifying credentials.
At C:\Windows\TEMP\hudson6249932248540013738.ps1:4 char:12
+ rename-item <<<< -path $env:warFilesFolder -newname $env:warFilesFolder+$((g
et-date).toString() -replace " ","_" -replace ":","-") -Credential $credential
+ CategoryInfo : InvalidArgument: (:) [Rename-Item], ParameterBin
dingException
+ FullyQualifiedErrorId : GetDynamicParametersException,Microsoft.PowerShe
ll.Commands.RenameItemCommand

Total time: 31 seconds
[MartServer] $ powershell.exe -NonInteractive -ExecutionPolicy ByPass "& 'C:\Windows\TEMP\hudson3864988451562351881.ps1'"
The provider does not support the use of credentials. Perform the operation aga
in without specifying credentials.
At C:\Windows\TEMP\hudson3864988451562351881.ps1:4 char:1
+ <<<< new-psdrive -name "N" -Root "\\win-el6hnngkvjo\c$\Git\Mart Remaining Fi
les" -PSProvider "FileSystem" -Credential $credential
+ CategoryInfo : NotImplemented: (:) [], PSNotSupportedException
+ FullyQualifiedErrorId : NotSupported

any idea how to get past this issue with the powershell command?

& : The term 'C:\Windows\System32\bash.exe' is not recognized as the name of a cmdlet, function, script file, or 
operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try 
again.

I'd like to have a "secure" switch which:

• Doesn't use -ExecutionPolicy Bypass 
• And doesn't append "exit $LastExitCode" to the script.

The reason being that this allows for use in a secure environment that enforces script signing. Previously this wasn't a big deal but since PowerShell 5 where you can audit scripts run with Bypass, and otherwise prevent their execution, it would be good.

I was able to run the following, before installing this plugin. So what functionality does this plugin give me that I don't have with Jenkins by default? Thanks

pipeline {
     agent any
     stages {
         stage ('Test PS') {
             steps {
                 script {
                     powershell 'Write-Output "Hello, World!" '

The url encoded string doesnt work with powershell plugin. Gitlap api need project name in url encoded format. https://docs.gitlab.com/ee/api/README.html#namespaced-path-encoding

powershell '''

curl "https://gitlanb.com/group%2fprojectname"

'''

above script always return 404 even thought path is correctly encoded.

Anyway to add a -Verbose option to the script call?

This will be useful when debugging server issues when there is no access to the underlying system.

-Verbose:($true|$false)

Thank you!