How Powershell Behaves with Errors in the Script

PowerShell has two kinds of errors; terminating errors and non-terminating errors

Terminating errors are the errors that can stop command execution cold. Non-terminating errors provide an additional challenge, as you need to be notified of failed operations and continue with pipeline operations. Powershell by default tries to continue when non-terminating errors occur. Something I don't want to happen when I call Powershell with my CI server to release software. If there are errors I want the script to stop and tell me what is wrong - not the script to continue and report that everything went OK.

$ErrorActionPreference is a variable that describes how PowerShell will treat non-terminating errors. $ErrorActionPreference has four self-explanatory options:

• Continue (the default)
• SilentlyContinue
• Inquire
• Stop

To exit your script with an error code (if an error occurred), you'll need to exit using the $LastExitCode variable. This variable returns a number that represents the exitcode of the last script or application, needed for your CI server to know if the script ran successfully. Here's a template for what I use with the Jenkins CI server...

$ErrorActionPreference = "Stop"

# Do something...

exit $LastExitCode

Anything else?

Well, yeah... $error is an array of all the errors that have occurred in the current session up to the number specified in $MaximumErrorCount. Also, $? is a boolean value that is $true if the previous operation succeeded and $false if it did not.

CQRS Commands (aka the write side)

Commands are created by a client, put onto a command bus for the server to process in it's domain. Commands are simple messages/requests to mutate state. It's not about editing data, but about performing tasks. Commands are always in imperative tense (present), asking the system to do something. As they are in the imperative tense, they are essentially questions and as the language suggests, the server has the right to refuse.

Command handlers handle these commands and are simple facades/coordinators over the domain below and methods should be thin; like MVC controller actions. Behaviours should be pushed down to the domain below and not exist in the handlers themselves. As each command changes state, it also typically results in events being pushed onto an event bus for recording and processing by event handlers.

Commands and events are very similar in design, only differing by their intentions. Events are described as verbs in the past tense. As the language suggests, it has already occurred, so no point in throwing exceptions. However, you can come up with a counter event. Event handlers typically insert data into denormalised database tables in the query database (the read side) but can perform a range of other tasks, such as send an email.

7 Ways to optimise Jenkins/Hudson

We've been having some 'difficulties' with Jenkins the past couple of weeks. This whitepaper from the guy that wrote most of the Jenkins core code looks like it could be interesting... 7 Ways to optimise Jenkins/Hudson.