running a powershell script

2,266 views
Skip to first unread message

Fredrik Skeel Løkke

unread,
Jun 8, 2014, 5:45:00 PM6/8/14
to go...@googlegroups.com
Hi

When running a powershell script in a task I get the error:

CommitStage.ps1 : The term 'CommitStage.ps1' 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.
At line:1 char:1
+ CommitStage.ps1
+ ~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (CommitStage.ps1:String) [], Com 
   mandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException
 

Any suggestion on how to define the task?

 <tasks>
              <exec command="powershell">
                <arg>CommitStage.ps1</arg>
                <runif status="passed" />
              </exec>
            </tasks>


Sriram Narayanan

unread,
Jun 8, 2014, 11:04:31 PM6/8/14
to Fredrik Skeel Løkke, go...@googlegroups.com
Is this .ps1 file present?

For e.g, if you were to specify "dir" instead of "powershell", do you see the file being listed?

-- Ram

Fredrik Skeel Løkke

unread,
Jun 9, 2014, 1:18:40 PM6/9/14
to go...@googlegroups.com, f.lo...@gmail.com
Yes, the file is present.

Running

<exec command="powershell">
                 <arg>ExecutionPolicy</arg>
                 <arg>ByPass</arg>
                 <arg>File</arg>
                 <arg>CommitStage.ps1</arg>
                <runif status="passed" />
              </exec>

 , did the trick.

Carl Reid

unread,
Jun 10, 2014, 6:21:24 AM6/10/14
to go...@googlegroups.com
Due to Powershell security restrictions you need to call scripts using the dot-slash notation .\ 

e.g. .\myscript.ps1

This will execute a script in the current directory.

In go this looks like the example below which is taken from an example pipeline job we use to deploy web applications. 


<exec command="%POWERSHELL%">
                <arg>.\Deploy\Deploy-WebApplication.ps1</arg>
                <arg>-WebsiteName #{website_name}</arg>
                <arg>-ApplicationName #{application_name}</arg>
                <arg>-SourceFilePath #{source_file_path}#{website_sourcefile_path}</arg>
                <arg>-FolderNamePattern 'yyyy_MM_dd_HH_mm'</arg>
                <arg>-RemovePreviousVersion</arg>
                <arg>-Verbose</arg>
                <runif status="passed" />
              </exec>
Powershell is declared as an environment variable which points to the sysnative version of Powershell to overcome the problems with 32 bit applications calling 64 bit processes.

e.g. 
 <environmentvariables>
        <variable name="POWERSHELL">
          <value>C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe</value>
        </variable>
 </environmentvariables>
As GO runs scripts locally there is no requirement to sign them and the best execution policy to have is "Remote-Signed" which is a good balance between security and getting things done.

You can set this once and for all on the server by opening an admin Powershell prompt and running:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

You will need to accept the warnings but then after this you can just run your scripts from the working directory using the notation specified above.

Good luck

Carl

Fredrik Skeel Løkke

unread,
Jun 11, 2014, 10:03:54 AM6/11/14
to go...@googlegroups.com
Thank you for the detailed answer.

Manoj Mahalingam

unread,
Jul 1, 2014, 10:17:02 AM7/1/14
to go...@googlegroups.com
I have written a Powershell plugin for Go. You can use it if you are using a version of Go that supports plugins - https://github.com/manojlds/gocd-powershell-runner

Carl Reid

unread,
Jul 1, 2014, 1:02:51 PM7/1/14
to go...@googlegroups.com
Just having a look at this now. We use Powershell in all our pipelines so this could be very useful to us.

The installation works perfectly.

Without testing it yet my immediate comment is the user interface does not seem to quite fit how we use powershell today.

  1. We either call existing functions within standard modules or custom modules or custom scripts. The user interface asks for a "Script file" but in the case of calling a function there would not be a script file.
  2. We often have a large number of parameters passed to the functions or to the scripts however the box entitled "Other parameters to powershell.exe" is very small. It would be much better to have a larger text box simmilar to the "arguments" box in the "more" task.

I will feedback more once I have used this.

Thanks

Carl
Reply all
Reply to author
Forward
0 new messages