Description

I have copied the exception handling from Invoke-Psake into the try/catch block of Invoke-Task so that we can trap errors and capture error detail before invoking the finally clause which calls TaskTearDown; this allows TaskTearDown to operate in the context of the current task's status including any error detail on failure.

This PR also proposes passing the $task parameter in the heart of Invoke-Task into TaskSetup and TaskTearDown as optional parameters so that instead of doing this:

taskSetup {
    "Begin task: '$($psake.context.Peek().currentTaskName)'"
}

we can do this:

taskSetup {
    "Begin task: '$($psake.context.Peek().currentTaskName)'"
}

Using the same technique in TaskTearDown and setting some additional properties on the Task instance we can now do this:

taskTearDown {
    param($task)

    if ($task.Success) {
        "'$($task.Name)' Tear Down: task passed!"
    } else {
        "'$($task.Name)' Tear Down: task failed with '$($task.ErrorMessage)'"
    }
}

Related Issue

#275 TaskTearDown doesn't have access to task_succeeded or task_error_message context

Motivation and Context

As explained in #275 I was looking for a way to refactor common plumbing out of my individual psake tasks and express them in common Setup and TearDown code, but wanted access to whether the current task passed or failed and if it failed, access to the error message.

How Has This Been Tested?

In the following environment, invoke-pester on the root folder shows that all existing specs pass and a few new ones demonstrate the additional opt-in syntax and behaviour.

My Environment

• Module version used: psake 4.7.4

• Operating System:
  

• PowerShell version:

PS C:\dev\psake-test> get-host

Name             : ConsoleHost
Version          : 5.1.17763.316
InstanceId       : cf5e4b3b-1d00-42e4-9bc7-3a84c02aa881
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.