Parallel Builds

The script Build-Parallel.ps1 is used in order to invoke several builds at the same time. It should be located in the same directory as Invoke-Build.ps1. Builds should be independent and should not conflict in any way.

Any number of builds is allowed, including 0 and 1, though normally there are 2+. Maximum number of parallel builds is limited by the number of processors by default and can be changed by the parameter.

Every script is invoked in its own runspace, as if PowerShell is just started. Build scripts should configure environment for their tasks. A calling script cannot do this. But it can prepare and pass some data via parameters.

Builds are specified by hashtables where keys and values are the Invoke-Build parameters. The extra entry Log tells to write build output to the specified file.

---

Example

Five parallel builds are invoked with various combinations of build parameters. Note that it is fine to reference a build script more than once if build flows specified by different tasks do not conflict:

Build-Parallel @(
    @{File='Project1.build.ps1'}
    @{File='Project2.build.ps1'; Task='MakeHelp'}
    @{File='Project2.build.ps1'; Task='Build', 'Test'}
    @{File='Project3.build.ps1'; Log='C:\TEMP\proj3.log'}
    @{File='Project4.build.ps1'; Configuration='Release'}
)

---

Build order is unknown

Build logs are shown in the same order as builds are specified in the list. But the order of start and completion times is not known or guaranteed to be always the same. That is why builds in the build list should be independent.

---

Avoid host cmdlets and UI members

Any user interaction and use of host cmdlets and UI members should be removed from scripts designed for parallel builds.

Alternatively, scripts may be prepared to work in standard and parallel modes differently. Use a script parameter in order to tell what the current mode is (say, the switch -NoUI may be used on calls by Build-Parallel).

A simple trick may work: check the host name. If it is Default Host then host cmdlets and members should be avoided, replaced with something, or redefined. Write-Host, for example, can be redefined for doing nothing.

# Define empty Write-Host for "Default Host"
if ($Host.Name -eq "Default Host") {
    function Write-Host {}
}

There are more things to avoid in parallel builds. This whole area is subtle. Even some PowerShell core features and commands may not work as expected.