Call a function from an InlineScript - powershell

How can I call a function in a workflow from a nested InlineScript?
The following throws an exception because the function is out of scope in the InlineScript:
Workflow test
{
function func1
{
Write-Verbose "test verbose" -verbose
}
InlineScript
{
func1
}
}
test

"The inlinescript activity runs commands in a standard, non-workflow Windows PowerShell session and then returns the output to the workflow."
Read more here.
Each inlinescript is executed in a new PowerShell session, so it has no visibility of any functions defined in the parent workflow. You can pass a variable to workflow using the $Using: statement,
workflow Test
{
$a = 1
# Change the value in workflow scope usin $Using: , return the new value.
$a = InlineScript {$a = $Using:a+1; $a}
"New value of a = $a"
}
Test
PS> New value of a = 2
but not a function, or module for that mater.

In the past I used the technique where I put all the common stuff in powershell module file, and do:
workflow Hey
{
PrepareMachine
ConfigureIIS
}
function PrepareMachine() {
Import-Module "MyCommonStuff"
CallSomethingBlahBlah()
}
function ConfigureIIS {
Import-Module "MyCommonStuff"
CallSomethingBlahBlah2()
}
You don't even have to wrap it in a module, you could just define the function out of workflow, and it would still work:
workflow Hey
{
InlineScript {
func1
}
}
function func1 {
Write-Output "Boom!"
}
That said, I was not impressed by workflows at all. Seems like quite pointless feature if you ask me. The most useful stuff about workflows is the ability to run things in parallel, but jobs can do it too. The idea above rant is that make sure you really do need workflows :)

Related

PDFCreator to convert pdf to txt in PowerShell

Updated Comment: I'm attempting to use PDFCreator to convert pdf files into txt files via PowerShell but it still doesn't seem to be working.
Any help is appreciated!
$PDFCreator = New-Object -ComObject PDFCreator.JobQueue
$PDF = 'C:\Users\userName\Downloads\SampleACORD.pdf'
$TXT = 'C:\Users\userName\Downloads\SampleACORD.txt'
try {
$PDFCreator.initialize()
if($PDFCreator.WaitForJob(5)){
$PJ = $PDFCreator.NextJob
}
if($PJ){
$PJ.PrintFile($PDF)
$PJ.ConvertTo($TXT)
}
} catch {
$_
Break
}
finally {
if($PDFCreator){
$PDFCreator.ReleaseCom()
}
}
You are getting that because $PJ is $null. NextJob isn't returning anything.
To guard against this, WaitForJob(int) returns a bool, $true if a job arrived and $false if not, so you should know after WaitForJob completes whether there is a job to get or not:
if( $PDFCreator.WaitForJob(5) ){
$PJ = $PDFCreator.NextJob
$PJ.allowDefaultPrinterSwitch('C:\Users\userName\Downloads\SampleACORD.txt', $true)
$PJ.ConvertTo($TXT)
} else {
# Handle the no jobs case here
}
You could also do a null check against $PJ before trying to call $PJ.allowDefaultPrinterSwitch:
if( $PJ ){
$PJ.allowDefaultPrinterSwitch('C:\Users\userName\Downloads\SampleACORD.txt', $true)
$PJ.ConvertTo($TXT)
}
Here is some more information on the PDFCreator.JobQueue API, which you may find useful.
To address your issue in the comments, where the file is not being produced, this page of the documentation explains the logical flow of how the conversion process should work:
Call the Initialize() method with your COM Object.
Call WaitForJob(timeOut) if you are waiting for one print job to get in the queue. The parameter timeOut specifies the maximum time the queue waits for the print job to arrive.
Now you are able to get the next job in the queue by calling the property NextJob.
Setup the profile of the job with the method SetProfileByGuid(guid). The guid parameter is used to assign the appropriate conversion profile.
Start the conversion on your print job with ConvertTo(path). The path parameter includes the full path to the location where the converted file should be saved and its full name.
The property IsFinished informs about the conversion state. If the print job is done, IsFinished returns true.
If you want to know whether the job was successfully done, consider the property IsSuccessful. It returns true if the job was converted successfully otherwise false.
In your case, I'm not sure how essential the profile would be, but it does look like your code fails to wait for completion. The following code will wait for the conversion job to finish (and check for success if you need to):
# Wait for completion
while( -Not $PJ.IsFinished ){
Start-Sleep -Seconds 5
}
# Check for success
if( $PJ.IsSuccessful ){
# success case
} else {
# failure case
}
Unrelated, but good practice, wrap your code in a try/finally block, and put your COM release in that block. This way your COM connection closes cleanly even in the event of a terminating error:
$PDFCreator = New-Object -ComObject PDFCreator.JobQueue
try {
# Handle PDF creator calls
} finally {
if( $PDFCreator ){
$PDFCreator.ReleaseCom()
}
}
The finally block is guaranteed to execute before returning to a parent scope, so whether the code succeeds or fails, the finally block will be run.

How to pass BUILD_USER from Jenkins to PowerShell

I'm having difficulty passing BUILD_USER from Jenkins to PowerShell. I'm using the Build User Vars plugin in Jenkins. I can output "${BUILD_USER}" just fine, but when I try to pass it to PowerShell, I get nothing.
Here's my current groovy file:
#!groovy
pipeline {
agent {
label 'WS'
}
stages {
stage ('Pass build user'){
steps {
wrap([$class: 'BuildUser']) {
script {
def BUILDUSER = "${BUILD_USER}"
echo "(Jenkins) BUILDUSER = ${BUILD_USER}"
powershell returnStatus: true, script: '.\\Jenkins\\Testing\\Output-BuildUser.ps1'
}
}
}
}
}
post {
always {
cleanWs(deleteDirs: true)
}
}
}
Here's my PowerShell file:
"(PS) Build user is $($env:BUILDUSER)"
Not sure what else to try.
def BUILDUSER = ... does not create an environment variable, so PowerShell (which invariably runs in a child process) won't see it.
To create an environment variable named BUILDUSER that child processes see, use env.BUILDUSER = ...

Jenkins Powershell write to console

I have a jenkins job that calls a powershell file. When I use it from a freestyle project it shows the powershell execution in the console output. Having switched it to a pipeline job I no longer see the output.
Currently my pipeline looks like this:
pipeline
{
stages
{
stage ('Deploy To Dev')
{
steps
{
powershell '"%WORKSPACE%\\SpearsLoad\\Scripts\\CIDeployToDev.Ps1"'
}
}
}
}
but I get no logging of the powershell steps.
Following the documentation I tried changing the stage to:
pipeline
{
stages
{
stage ('Deploy To Dev')
{
steps
{
node('Deploy the SSIS load')
{
//Deploy the SSIS load
def msg = powershell(returnStdout: true, script: '"%WORKSPACE%\\SpearsLoad\\Scripts\\CIDeployToDev.Ps1"')
println msg
}
}
}
}
}
but that gives:
Expected a step # line 123, column 6. def msg =
powershell(returnStdout: true, script:
'"%WORKSPACE%\SpearsLoad\Scripts\CIDeployToDev.Ps1"')
I feel like I am missing something quite fundamental. What am I doing wrong ?
You need to wrap your pipeline execution into script section, because you're trying to use scripted syntax in declarative pipeline:
script {
//Deploy the SSIS load
def msg = powershell(returnStdout: true, script: '"%WORKSPACE%\\SpearsLoad\\Scripts\\CIDeployToDev.Ps1"')
println msg
}
For anyone who comes here looking for answers, I need to point out that there were actually 3 separate problems with the code:
The lack of a script section as per the accepted answer.
The powershell was not actually running due to not calling it correctly
The powershell was not running due to spaces in the %WORKSPACE% variable
in the end, I went with:
script {
def msg = powershell(returnStdout: true, script: " & './SpearsLoad\\Scripts\\CIDeployToDev.Ps1'")
println msg
}
which actually works!
I use
Write-Host "My message"
in powershell. This will show up in the log.

Cross edition exception handling with Powershell web cmdlets

I have an existing PowerShell module that runs against Windows PowerShell 5.1. It depends heavily on the Invoke-WebRequest and Invoke-RestMethod cmdlets which have some fairly significant changes between 5.1 and PowerShell Core 6.
I've already managed to make most of the code work between editions (Desktop/Core), but the last thing I'm having trouble with is handling the exceptions thrown by HTTP failure responses. The existing code looks more or less like this.
try {
$response = Invoke-WebRequest #myparams -EA Stop
# do more stuff with the response
} catch [System.Net.WebException] {
# parse the JSON response body for error details
}
I don't necessarily want to trap any exceptions other than the ones generated by failing HTTP response codes from the server. The exception type returned on Core edition is different than Desktop edition and requires separate code paths to parse the response. So initially I tried this:
try {
$response = Invoke-WebRequest #myparams -EA Stop
# do more stuff with the response
} catch [System.Net.WebException] {
# Desktop: parse the JSON response body for error details
} catch [Microsoft.PowerShell.Commands.HttpResponseException] {
# Core: parse the JSON response body for error details
}
This works fine when running in Core. But when running in Desktop, I get a Unable to find type [Microsoft.PowerShell.Commands.HttpResponseException] error.
What's the best way to work around this? Do I need to just catch all exceptions, string match on the type, and re-throw what I don't want? Is there a more elegant way I'm missing that doesn't involve releasing separate versions of the module for Desktop and Core versions of PowerShell?
I might recommend that you make thin wrapper around the cmdlets that does exception handling, and maybe you create a consistent exception class of your own and each version throws the same one.
At run time, you determine your version/edition, and set an alias to which one you want to use.
Example:
function Invoke-PS51WebRequest {
[CmdletBinding()]
param(...)
try {
Invoke-WebRequest #PSBoundParameters -EA Stop
# return the response
} catch [System.Net.WebException] {
# create a new exception
throw [My.Custom.Exception]$_
}
}
function Invoke-PS6XWebRequest {
[CmdletBinding()]
param(...)
try {
Invoke-WebRequest #PSBoundParameters -EA Stop
# return the response
} catch [System.Net.WebException] {
# Desktop
throw [My.Custom.Exception]$_
} catch [Microsoft.PowerShell.Commands.HttpResponseException] {
# Core
throw [My.Custom.Exception]$_
}
}
switch ($PSVersionTable)
{
{ $_.Is51 } { Set-Alias -Name Invoke-WebRequest -Value Invoke-PS51WebRequest -Force }
{ $_.Is6X } { Set-Alias -Name Invoke-WebRequest -Value Invoke-PS6XWebRequest -Force }
}
try {
Invoke-WebRequest #myParams -ErrorAction Stop
} catch [My.Custom.Exception] {
# do something
}
This needs a lot of work (parsing the exceptions properly, maybe making more than 2 of these variations, determining which platform you're on for real as $PSversionTable.Is51 and .Is6X aren't real, creating your own exception class, creating a proper instance of it instead of casting $_ to it, etc.).
I also demonstrated overriding the actual name Invoke-WebRequest, but I recommend using your own name Invoke-MyCustomWebRequest and using that throughout your code instead. It will keep things more manageable.

Why doesn't Pester catch errors using a trap

I'm wondering why I get the following behaviour when running this script. I have the script loaded in PowerShell ISE (v4 host) and have the Pester module loaded. I run the script by pressing F5.
function Test-Pester {
throw("An error")
}
Describe "what happens when a function throws an error" {
Context "we test with Should Throw" {
It "Throws an error" {
{ Test-Pester } | Should Throw
}
}
Context "we test using a try-catch construct" {
$ErrorSeen = $false
try {
Test-Pester
}
catch {
$ErrorSeen = $true
}
It "is handled by try-catch" {
$ErrorSeen | Should Be $true
}
}
Context "we test using trap" {
trap {
$ErrorSeen = $true
}
$ErrorSeen = $false
Test-Pester
It "is handled by trap" {
$ErrorSeen | Should Be $true
}
}
}
I then get the following output:
Describing what happens when a function throws an error
Context we test with Should Throw
[+] Throws an error 536ms
Context we test using a try-catch construct
[+] is handled by try-catch 246ms
Context we test using trap
An error
At C:\Test-Pester.ps1:2 char:7
+ throw("An error")
+ ~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (An error:String) [], RuntimeException
+ FullyQualifiedErrorId : An error
[-] is handled by trap 702ms
Expected: {True}
But was: {False}
at line: 40 in C:\Test-Pester.ps1
40: $ErrorSeen | Should Be $true
Question
Why is the trap{} apparently not running in the final test?
Here are two solutions to the problem based on the comments/suggested answers from #PetSerAl and #Eris. I have also read and appreciated the answer given to this question:
Why are variable assignments within a Trap block not visible outside it?
Solution 1
Although variables set in the script can be read within the trap, whatever you do within the trap happens to a copy of that variable, i.e. only in the scope that is local to the trap. In this solution we evaluate a reference to $ErrorSeen so that when we set the value of the variable, we are actually setting the value of the variable that exists in the parent scope.
Adding a continue to the trap suppresses the ErrorRecord details, cleaning up the output of the test.
Describe "what happens when a function throws an error" {
Context "we test using trap" {
$ErrorSeen = $false
trap {
Write-Warning "Error trapped"
([Ref]$ErrorSeen).Value = $true
continue
}
Test-Pester
It "is handled by trap" {
$ErrorSeen | Should Be $true
}
}
}
Solution 2
Along the same lines as the first solution, the problem can be solved by explicitly setting the scope of the $ErrorSeen variable (1) when it is first created and (2) when used within the trap {}. I have used the Script scope here, but Global also seems to work.
Same principle applies here: we need to avoid the problem where changes to the variable within the trap only happen to a local copy of the variable.
Describe "what happens when a function throws an error" {
Context "we test using trap" {
$Script:ErrorSeen = $false
trap {
Write-Warning "Error trapped"
$Script:ErrorSeen = $true
continue
}
Test-Pester
It "is handled by trap" {
$ErrorSeen | Should Be $true
}
}
}
According to this blog, you need to tell your trap to do something to the control flow:
The [...] thing you notice is that when you run this as script, you will receive both your error message and the red PowerShell error message.
. 'C:\Scripts\test.ps1'
Something terrible happened!
Attempted to divide by zero.
At C:\Scripts\test.ps1:2 Char:3
+ 1/ <<<< null
This is because your Trap did not really handle the exception. To handle an exception, you need to add the "Continue" statement to your trap:
trap { 'Something terrible happened!'; continue }
1/$null
Now, the trap works as expected. It does whatever you specified in the trap script block, and PowerShell does not get to see the exception anymore. You no longer get the red error message.