Your profile picture is used as the logo for your personal space. Change your profile picture.
View PowerShell on the plugin site for more information.
Integrates with Windows PowerShell by allowing you to directly write PowerShell scripts into the text box in Jenkins. Other than that, this plugin works pretty much like the standard shell script support.
Fixed a quotation problem.
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?
Now if this is still a problem I could investigate in signing the generated ps1 file such that thing could work with AllSigned as policy. Though that will anyhow require specifying and registering a valid trusted cert for signing.
What might however do the trick also is letting you specify a ps1 file for yourself, such that your file gets executed. I was planning to add this extension anyhow. Perhaps I may find time to add this somewhere this week.
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.
> 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) ?
Same problem here. If Hudson doesn't know that the build fails then that's a big problem. I'm going to try Michael's batch-script-wrapper technique!
How can I pass arguments while calling a powershell script?
How do I tell Hudson to always run Powershell scripts with ExecutionPolicy="Unrestricted" (or RemoteSigned, whatever)?
Thank you in advance!
As I understand it, PowerShell v2 has solved the execution policy problem for you.
What about the issue of not returning a pass/fail value? Is that still a problem?
Easy when you know how! Hope this is useful to others.
I actually found that simply installing v2 did not solve the execution problem. I had to use set-executionpolicy RemoteSigned for it to work, but it now works.
I've had the problem with the temp powershell script "cannot be loaded because the execution of scripts is disabled on this system".
In my case, I already had Powershell 2 as I was on windows 7, but it was 64bit windows 7, and somebody installed the 32 bit version of Java to run hudson under (as they were used to working on XP). 32 bit Java can only run 32 bit batch shell's and powershell shell's.
After uninstalling 32bit java, and installing 64 bit java, Hudson kicked off 64 bit batch and powershell shells and worked fine.
Hopefully that helps someone else.
The parameter tst is not found.
Sometimes you might want to use 32-bit Java on a 64-bit system, for example if you are calling 32-bit native code from Java.
In that case, you can use the PowerShell (x86), which is installed side-by-side with 64-bit version.
You need to set execution policy separately for x86 and 64-bit.
How exactly did you accomplish this? I have only 64bit java installed, and yet Jenkins is still spawning 32bit command windows. Where is this configured?
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 ?
Were you able to figure this out? I'm running into the same problem and can't seem to solve it.
I did as you suggested here and replaced the JRE subfolder of Jenkins with the 64bit version and it worked.
However, I don't know if this is a permenant solution. Won't Jenkins try to reinstall the version of Java it thinks it should install at some point?...
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.
You should have Jenkins working on whatever java version you want.
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.
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).
Thank you Brian. I've forwarded your comments to our team and if we come up with any solutions I'll respond here.
It may be that when you install Jenkins as a Windows service, that if it is installed as 32bit, that you can't change that unless you reinstall the Windows Service. I'll have to play around and test some more to see...
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?
Value doesn't show up. Anyone see what I am doing wrong?
I was thinking of trying this myself but I doubt it will work. Jenkins is probably starting the PowerShell process with a copy of the environment so anything you do in that environment will not be seen in the launching process. This is pretty normal and it is what lets the 'child' processes muck around with things like the PATH without screwing up the 'parent'. All the children get a copy and can change the PATH all they want without breaking the invoker.
I do have the same need to pass information back from the PowerShell script however. I know this is a hack, but the only two things I can think of are 1) write something to a well known key in the registry and 2) write something to a well known log file and pull the results from there.
I will post back what I hack together if you are interested (and I can get it working).
I have powershell version 3.0 installed and when I try to run a powershell command or script, i still get the same error.
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!
Hope this helps!
I ran the execution policy as admin and still got the same error. I found a patch for this.
Current LastExitCode support is not full.
If there is syntax error in .\make.ps1, 'if ($LASTEXITCODE)' part skipped, but powershell self exits with 1.
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.
specifying credentials.
in without specifying credentials.
any idea how to get past this issue with the powershell command?
again.
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.
Unfortunately, plugin does not work (I tried it in jenkins 2.107.2). So, thank you for hint on how to use it without plugin.
Would like like to see if the Groovy script variables can be sent to the power shell script ?
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.
Thank you!
Powered by a free Atlassian Confluence Open Source Project License granted to Jenkins. Evaluate Confluence today.
