Automatic Build Triggering
  • 10 May 2021
  • 2 Minutes to read
  • Dark
    Light
  • PDF

Automatic Build Triggering

  • Dark
    Light
  • PDF

Automatic Build Triggers are primarily designed to monitor your source control repository and create a new build whenever someone makes changes. This is generally called continuous integration and provides immediate feedback on problems with code changes, whether through basic compilation or by running unit tests and other automated tests. This also means builds are ready to deploy sooner for further testing.

This feature isn't limited to only creating builds on change, and you could use the a Scheduled Build Trigger to deploy a build to a testing environment on a nightly basis.

BuildMaster supports three general types of build triggers:

The default behavior of each of these triggers is to create a new build in either all active releases, the latest release, or a specific release (which could be a number or a variable, such as a application-defined $TriggerReleaseNumber).

Executing Custom OtterScript on Trigger

You can also configure a build trigger to execute a custom plan, which allows you to enter the name of an application-level or system-level OtterScript plan.

During execution, any additional context from the commit will be available via deployment variables to support more complex use-cases:

  • Automatically creating a release & build when a new branch is created by combining the Ensure-Release and Create-Build operations
  • Sending an email notification when a change is detected using the Send-Email operation
  • Create builds for multiple releases or spanning multiple applications

Example OtterScript

The following OtterScript is essentially what will execute when you configure a Git repository monitor that creates builds against the latest release, and select the option to create $Branch and $CommitHash variables on build.

Set-BuildVariable Branch
(
    Value: $Branch
);
Set-BuildVariable CommitHash
(
    Value: $CommitHash
);
Create-Build
(
    Application: $ApplicationName
);

This is mostly for reference; if you wanted this exact behavior, you should just use the built-in create a new build function.

System-level & Shared Build Triggers

You can also create build triggers at the system-level, which can be particularly useful if you have a lot of similar applications that use similar conventions.

For example, on our public instance of BuildMaster, a number of our applications are configured to use a shared GitLab webhook monitor, and has some advanced selection logic to determine which application to create a build in:

Log-Debug "Webhook received for $Repository repository (Branch=$Branch)";
if $Repository == inedo-docs
{
    Create-Build
    (
        Application: Docs.Inedo.Com,
        Variables: %(Branch: $Branch)
    );
}
else if $Branch == master
{
    if $MatchesRegex($Repository, ^inedox-.`$*)
    {
        set $appName = $Substring($Repository, 7);
        Log-Debug "Looking for $appName application...";
    
        Log-Debug `$ApplicationExists(`$appName) = $ApplicationExists($appName);
    
        if $ApplicationExists($appName)
        {
            Log-Debug "$appName application found. Creating build...";
        
            Create-Build
            (
                Application: $appName
            );
        }
    }
    
    if $Repository == upack || $Repository == Inedo.UPack
    {
        Create-Build
        (
            Application: $Repository
        );
    }
    
    if $Repository == inedo-docs-jp
    {
        Create-Build
        (
            Application: InedoDocs-jp,
            Variables: %(Branch: $Branch)
        );
    }
}

Was this article helpful?