Build And Release Management

Quick Links

  » Inserting build step at arbitrary location
  » Setting default values in build parameters
  » Setting template parameters in log and result paths
  » Running builds against Perforce change lists and labels
  » Auto-publishing build results
  » Using change list numbers as build numbers
  » Initializer step to support parallel builds
  » Pinning build result at publishing time
  » Reporting results of parallel builds on leader result page
  » Ignoring result timestamp
  » Configuring dependent builds
  » Shell variables to hold number and date for previous build change list

Inserting Build Step At Arbitrary Location

This feature greatly simplifies managing build steps. Now it is possible to insert a build step where it is need:

Setting Default Values In Build Parameters

Now build parameters can have default values. If set, the default values are be passed to the build script. Whether a build is run manually or automatically, these parameters are still be available:

Setting Template Parameters in Log and Result Paths

It is possible to use template parameters in log and result paths. The supported parameters are build.date, build.name, build.number, build.run.id, build.timestamp, change.list.number and step.name. This feature allows specifying paths specific to a particular build execution context:

Running Builds Against Perforce Change Lists And Labels

Parabuild can run a manual build against an arbitrary change list number of a label in Perforce depot.

Auto-Publishing Build Results

Parabuild provides a configuration parameter to publish a build result automatically:

Using Change List Numbers as Build Numbers

It is now possible to use Perforce change list numbers as build numbers. A global configuration option enables this feature:

Initializer Step To Support Parallel Builds

Parabuild allows setting a fist step of a build as "Initializer". If the build is a leader in a group of parallel builds, Parabuild runs the initializer step before starting parallel builds. This feature may be used to prepare build and to send it to parallel builders using such scp or such. Finalizer step runs after all parallel builds have finished.

Pinning Build Result At Publish Time

It is possible to pin a build result at the time the result is published:

Reporting Results Of Parallel Builds On Leader Result Page

Parabuild has an option to report to report results of a parallel build on build leader's result page. This allows for quick access to results of the parallel build without switching between builds.

Ignoring Result Timestamp

Sometimes it is necessary to archive the result produced by the previous build runs as a result produced by the current build run. Check box "Ignore time stamp" to enable archiving the results produced by the previous build runs.

Configuring Dependent Builds

If a build run was successful, Parabuild may start other build. To enable starting other build, select the build using selection list "Start build on success" in the "Dependent Build".

Shell Variables to Hold Number And Date For Previous Build Change List

Parabuild provides shell variable PARABUILD_PREVIOUS_CHANGE_LIST_NUMBER and PARABUILD_PREVIOUS_CHANGE_LIST_DATETIME to the build commands. This variable contains a change list number that Parabuild used to run a check out for a previous build. A build script can use this variable to perform advanced operations on a local workspace such as finding what what changes since the previous build run.

« New features in software configuration management