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

App Mapping

Github (PRs)	`last commit build status` or `last commit checksuite status` GitHub combines the build statuses and checks of the last commit into one overall status, which Keypup maps. A commit with no status or check is `NONE`. Mapping: `PENDING` => `IN_PROGRESS` `ERROR` => `FAILURE` `FAILURE` => `FAILURE` `SUCCESS` => `SUCCESS` `EXPECTED` => `ACTION_REQUIRED`
Gitlab (PRs)	`head pipeline status` A pipeline still running with no update for a day is counted as `FAILURE`. 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` When a pull request has several builds, it is `SUCCESS` only when all of them are successful. Otherwise, any build in progress makes it `IN_PROGRESS`, then any failed, stopped or cancelled build makes it `FAILURE`. A build still in progress with no update for a day is counted as failed. Mapping: `INPROGRESS` => `IN_PROGRESS` `FAILED` => `FAILURE` `STOPPED` => `FAILURE` `SUCCESSFUL` => `SUCCESS`
Azure DevOps (PRs)	`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).

Issues and PRs > Build status

App Mapping

Reporting Use Cases