Skip to main content

Issues and PRs > Build status

Tom Williams avatar
Written by Tom Williams
Updated yesterday

Dataset: Issues & Pull Requests

Entity: Pull Requests

Field ID: build_status

Type: Select list

Description: The state of the Continuous Integration (CI) as exposed by the code management platforms (e.g. GitHub, GitLab). Possible values are:

  • NONE no builds detected

  • IN_PROGRESS the build is pending or currently running

  • FAILURE the build failed to complete due to an error, a timeout or because it was cancelled

  • SUCCESS the build completed successfully or was skipped

  • ACTION_REQUIRED the build requires a manual action from the user

Source: App

Transformation logic: N/A

From:

Github (PRs)

last commit build status or last commit checksuite status

Mapping:

  • IN_PROGRESS => IN_PROGRESS

  • PENDING => IN_PROGRESS

  • QUEUED => IN_PROGRESS

  • REQUESTED => IN_PROGRESS

  • WAITING => IN_PROGRESS

  • CANCELLED => FAILURE

  • ERROR => FAILURE

  • FAILURE => FAILURE

  • STARTUP_FAILURE => FAILURE

  • TIMED_OUT => FAILURE

  • SKIPPED => SUCCESS

  • NEUTRAL => SUCCESS

  • SUCCESS => SUCCESS

  • EXPECTED => ACTION_REQUIRED

  • ACTION_REQUIRED => ACTION_REQUIRED

Gitlab (PRs)

head pipeline status

Mapping:

  • created => IN_PROGRESS

  • pending => IN_PROGRESS

  • preparing => IN_PROGRESS

  • running => IN_PROGRESS

  • scheduled => IN_PROGRESS

  • waiting_for_resource => IN_PROGRESS

  • failed => FAILURE

  • canceled => FAILURE

  • success => SUCCESS

  • skipped => SUCCESS

  • manual => ACTION_REQUIRED

Bitbucket (PRs)

build status

Mapping:

  • INPROGRESS => IN_PROGRESS

  • FAILED => FAILURE

  • STOPPED => FAILURE

  • SUCCESSFUL => SUCCESS

Azure DevOps (PRs, Issues)

last merge commit build statuses

When a commit has several statuses, the returned status is based on the order of precedence below ("rollup status").

Mapping by order of precedence:

  • error => FAILURE

  • failed => FAILURE

  • pending => IN_PROGRESS

  • succeeded => SUCCESS

  • notSet => NONE

JIRA (Issues)

N/A

ClickUp (Issues)

N/A
​

Trello (Issues)

N/A

Reporting Use Cases

The Build Status field is critical for monitoring the health of your CI/CD pipeline and enforcing quality standards. As a text field with a fixed set of values, it is ideal for filtering, creating compliance metrics, and analyzing the stability of your codebase.

  • Filtering and Triage: You can quickly identify pull requests that require immediate attention based on their build outcome.

    • Identify Broken Builds: Create a high-priority list of open pull requests that need to be fixed by using a filter like Build Status = "FAILURE".

    • Compliance Audits: You can audit your merge practices by creating a report of all merged pull requests that had a failing build at the time of merge. This is done by filtering where State = "MERGED" and Build Status = "FAILURE".

    • Find Ready-to-Merge PRs: Combine with other fields to find pull requests that are approved and have a successful build, and are therefore ready to be merged: Build Status = "SUCCESS" and Review State = "APPROVED".

  • Reporting and Trend Analysis: Using Build Status as a dimension allows you to visualize the health of your CI/CD pipeline over time.

    • Build Outcome Distribution: A pie chart with Build Status as the dimension and COUNT() as the metric can show you the proportion of successful, failed, and in-progress builds across all your pull requests.

    • Failure Rate Over Time: Track the stability of your codebase with a line chart that uses a time-based dimension (e.g., YEAR_MONTH(created_at)) and a metric that counts only the failures: COUNT_IF(build_status == "FAILURE"). A rising trend could indicate a growing problem with technical debt or testing.

  • Custom Formulas and KPIs: You can create powerful key performance indicators to measure the effectiveness of your testing and integration processes.

    • Green Build Ratio: One of the most important metrics you can build is the percentage of pull requests that are merged with a successful build. This can be calculated with a custom formula like: ROUND(COUNT_IF(build_status == "SUCCESS") / COUNT() * 100, 2).

Did this answer your question?