Build Completion Tracking

The Challenge

Build systems face a critical tracking challenge: how to ensure visibility into builds that start but never complete? Traditional duration-only tracking misses failed or hung builds entirely.

The Solution: Lifecycle Claims

As in the previous example about ABCo, we'll post evidence about the build execution. We're now going to post a BuildStartedEvent at the beginning of the process and when the build completes we'll send a BuildCompleted event.

In order to track whether all initiated builds complete we'll create a BuildLifecycle claim with a completed=false property when we start the build using the BuildStartedEvent as the basis for that claim.

When a build completes, we revise the claim using the BuildCompleted evidence as the basis:

• completed → true

• duration → actual elapsed time

• Additional evidence links to completion logs

Create The Evidence Types

We have a head start now as the articles and sources already exist in our repo - we'll reuse them for this exercise

Let's define two new Evidence Types:

BuildStartedEvent

Properties

• buildId

  • Type: Text

  • Description: Unique identifier for start of the build

  • Required: Yes

  • List: No

BuildCompleted

Properties

• buildStatus

  • Type: Enum

  • Description: The source of data about the performance of each build job

  • Required: Yes

  • List: No

  • Enum Options:

    • success

    • failure

• duration

  • Type: TimeSpan

  • Description: Elapsed time of build

  • Required: Yes

  • List: No

Create The BuildLifecycle Claim Type

Properties

• completed

  • Type: Boolean

  • Description: Did the build complete?

  • Required: Yes

  • List: No

At this point we could begin posting both BuildStartedEvents and BuildCompleted evidence. As before we can play ahead and define the claims that will compute SLA Compliance as well as claims about completion statuses.

Monitoring Incomplete Builds

A computed claim identifies builds exceeding SLA without completion:

As in the previous SLA example we'll define a Constant $id using date variables - in this case we're using the date-MonthName-4 digit year

Next we'll define the collector

• Name:dependantStatusCollector

• Assertion Type: BuildLifecycle

• Count: 1000

• Require exact amount: No

• Date Offset: CurrentMonth

• Property to Collect: completed

Next we'll need to create 3 properties

totalCount

• Type: Integer

• Description: Total builds executed

• Required: Yes

• List: No

• Expression: count

completedCount

• Type: Integer

• Description: Completed builds executed

• Required: Yes

• List: No

• Expression: trueCount

incompleteCount

• Type: Integer

• Description: Count of builds started but not completed

• Required: Yes

• List: No

• Expression: falseCount

Then we'll need to set a trigger:

Trigger: BuildLifecycle

SLA Compliance

Now that we have the SLA compliance covered, let's build out the BuildLifeCycleSLA performance claim.

About: BuildService

Collector

• Name:buildLifecycleCollector

• Assertion Type: BuildCompleted

• Count: 1000

• Require exact amount: No

• Date Offset: CurrentMonth

• Property to Collect: duration

Properties

metSLA

• Type: Percentage

• Description: Percentage of builds meeting SLA

• Required: Yes

• List: No

• Expression: percentLessThanTimeSpan

  • Variable (Collector): buildLifecycleCollector

  • Threshold

    • Constant

    • Value: 500

    • Unit: Seconds (s)

Seeing the results

Below are the two summary claims created after the first 10 builds in July of 2025

• 8 completed

• 2 did not

• Only 12.5% met the agreed upon SLA