Post Action Scripts

[mkellerman]

Is your Enhancement request related to a problem? Please describe

Would be nice if we could launch another script, as a Post Action Script, AND import all variables from the primary/parent script execution.

ex:

Invoke-VMCreation.ps1

• UA provides a variable $UDJob with context of the job being ran (JobName, JobID, StartTime, StartedBy (Manual, Schedule).. etc
• The script itself generated a variable called $VM get's during its execution.

Post Script Executed: Invoke-SlackNotification.ps1

• UA provides a variable $UDJob, which is the same as before, but with additional properties (EndTime & Result/Status).
• This post script would have access to all the variables ($VM) from the primary/parent script, so we can send a slack notification to a team, with additional information from the $VM.

The reason we need a Post script, is in the event that the script fails due to out of memory, or a hard crash.. We still want to as a Post step.. something that we are 100% sure that will get executed no matter what at the end of that first script.

This would also resolve the need for UA to provide a notification service. Users could create their own Notification Service, as a POST step.. based on the $UAJob.Status.

If I want to use Twitter for my notifications, I can import PSTwitterAPI.. if I want to send an email, or Teams.. whatever I want.. I can import and manage whatever messaging service I want.

Less dependancy on the UA developer(s) to provide every possible post action notification service under the sun. ;)

[adamdriscoll]

Is this the same as this issue? https://github.com/ironmansoftware/universal-automation/issues/38

We were thinking of having different events that you could subscribe to.

[mkellerman]

After some thinking.. here are my thoughts:

[ Scripts ]

id	Name	Status	LastExecution	Scheduled	Actions
1	Invoke-TwitterAction	Success	35m	Every 4h	[ > Run ] [=]
1	Send-EmailNotification	Success	35m	-	[ > Run ] [=]

* Click on the script name to view directly (Remove .ps1, as they will always be a .ps1)
* [=] Hamburger with more options (ex: Edit, Rename Delete, Schedule)

[ Workflows ]

id	Name	Actions
1	Invoke-WithNotifications	[ > Run ] [=]

* Workflows are simple .ps1 wrappers, and allows to run scripts within a workflow.
* This allows the workflow to always be source controlled as well.
* Workflows would provide some kind of environment variables which help tailor the workflow (ex: $env:UAScriptID)
* Some UA functions would be accessible from within a workflow (ex: Invoke-UAScript)
* When clicking [ > Run ], it would prompt for the powershell version, and the sript you want to run. 

# Example of Invoke-WithNotifications.ps1:
param()
Begin {
    $ErrorActionPreference = Stop
}
Process {
    Invoke-UAScript -Id ${env:UAScriptID}
}
End {
    # Insert step for notification as you want it
    If ($Error) {
        $ArgumentList = @{
            To = 'user@company.com'
            Title = 'Script Failed'
            Message = '(╯°□°)╯︵ ┻━┻'
        }
        Invoke-UAScript -Name 'Send-EmailNotification' -ArgumentList $ArgumentList
    } Else {
        $ArgumentList = @{
            To = 'user@company.com'
            Title = 'Script Success'
            Message = '¯\_(ツ)_/¯'
        }
        Invoke-UAScript -Name 'Send-EmailNotification' -ArgumentList $ArgumentList
    }
}

[adamdriscoll]

@mkellerman @leeberg - So I'm seeing this more of just another script than a workflow.

We could think about doing something like this but I wonder if really gives us more than just what scripts give us now.

For example, you could effectively put a parameter at the top of this workflow and enter a script name (or provide some sort of selector experience) and then just manage this as any other script. You could even have a script that calls this script template with the parameter defined and make that the script you actually start.

I've been hesitant to just jump into workflow\pipeline\event scenarios because I worry that if we do it wrong it will complicate the experience. I'm glad we're having this discussion because it does seem like something people want.

I think we need to ensure that we get a couple of things right about workflows\pipelines.

• They are easy to define
• They are easy to see what will happen
• They are easy to report what actually happened
• They are easy to debug when what was supposed to happen, didn't

So all-in-all, I think we need to weigh the pros\cons of doing something free form like a script-like workflow as you've described and potentially something more structured.

I see the benefit of having some sort of script template so you don't have to redefine the same logic over and over again but I just want to make sure that it's something we really need to build in to the platform itself.

[mkellerman]

Agreed.

Let’s schedule a Skype (inc @leeberg) call and discuss, then write down here what we come up with, and have others comment/review if need be.

How does that sound?