> ## Documentation Index
> Fetch the complete documentation index at: https://docs.endorlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Block pull requests on findings

> Gate merges on PR scan findings using action policies and required status checks.

A PR scan reports findings, but it does not block a merge on its own.

To gate a pull request, ensure that you have the following configurations:

* An action policy that breaks the build when the findings you care about appear.
* A required status check in your source control manager that enforces the result before a merge.

The action policy decides which findings block a pull request, and the required status check is what stops the merge.

## Create an action policy that breaks the build

In Endor Labs, create an action policy and choose the **Break the Build** enforcement action. Select the policy template for the finding types you want to gate, such as SCA, secrets, or SAST. The policy applies to PR scans the same way it applies to other scans.

See [Create an action policy from template](/platform-administration/policies/action-policies#create-an-action-policy-from-template) for the full procedure.

## Configure the required status check in GitHub to block merges

GitHub blocks a merge only when the Endor Labs check is a required status check on the target branch. The check you require depends on how Endor Labs scans your pull requests. The check appears as a selectable option only after it has reported on a pull request within the last seven days. Open or update a pull request so the Endor Labs check runs once, then add it to your branch protection rule.

To add the check to a branch protection rule:

1. In your GitHub repository, select **Settings** > **Branches**.
2. Next to the rule for your default branch, click **Edit**.
3. Select **Require status checks to pass before merging**.
4. Enter the check name (**Endor Labs Automated Scan** for the GitHub App, or your workflow job name for GitHub Actions), and select it from the results.
5. Click **Save changes**.

To create a rule instead, click **Add branch protection rule**, enter a **Branch name pattern**, and follow the same steps.

GitHub also supports requiring status checks through repository and organization rulesets, which GitHub now recommends. Use an organization ruleset to enforce the check across many repositories at once. For more information, refer to [About rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets).

After you require the check, GitHub keeps the merge blocked until the check passes. A check that concludes as neutral or skipped does not block the merge, even when it is required. Endor Labs reports a neutral result when there is nothing to scan, such as a pull request with no relevant changes.

For more information, see [Managing a branch protection rule](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule) and [About rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets), and [Troubleshooting required status checks](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks) in the GitHub documentation.

## Configure the required status check in Azure DevOps to block merges

To block pull requests from merging, configure a branch policy that requires the Endor Labs pull request status. The merge is blocked until the status succeeds. The Azure DevOps App posts this status as **endorlabs/Endor Labs Automated Scan**, which is what you select when you create the branch policy.

You can select the status only after Endor Labs posts it to a pull request at least once. Open or update a pull request to let the scan run, and then add the branch policy. You can also enter **Genre** and **Name** manually before the first scan.

To require the status on your default branch:

1. In Azure DevOps, select **Project settings** > **Repositories**.
2. Search for and select your repository.
3. Select **Policies**.
4. Under **Branch Policies**, select your default branch, such as `main`.
5. Next to **Status checks**, click **+**.
6. Select **endorlabs/Endor Labs Automated Scan** as the status to check.
7. Set **Policy requirement** to **Required**.
8. Optionally, set **Authorized identity** to the account that the Azure DevOps App authenticates with. Only statuses posted by that account satisfy the policy.
9. Under **Reset conditions**, clear **Reset status whenever there are new changes**. Endor Labs binds each status to the pull request iteration it scanned, so the reset keeps the merge blocked until the latest scan succeeds.
10. Click **Save**.

The status fails when a finding matches an action policy set to **Break the Build**, and also when the scan itself fails to complete. Findings that match a **Warn** action policy still generate pull request comments, but the merge is not blocked.

A **Not Applicable** status does not block a merge, even if the **Policy requirement** is set to **Required**. Endor Labs reports this status when the base branch of the pull request has not yet been scanned, or when the scan could not be performed.

For more information, refer to [Configure a branch policy for an external service](https://learn.microsoft.com/en-us/azure/devops/repos/git/pr-status-policy) and [Iteration status](https://learn.microsoft.com/en-us/azure/devops/repos/git/pull-request-status#iteration-status).

## Block merges for PR scans run from Azure Pipelines

When you run `endorctl` in an Azure Pipelines job instead of using the Azure DevOps App, Endor Labs does not post a pull request status. If a finding matches an action policy set to **Break the Build**, `endorctl` exits with [code 128](/best-practices/troubleshooting/endorctl-exitcodes), causing the pipeline job to fail. See [Scanning in Azure Pipelines](/setup-deployment/ci-cd/scan-with-azuredevops) to learn how to configure the pipeline.

To block merges based on findings, configure a build validation policy for the pipeline that runs the Endor Labs scan. The merge remains blocked until the pipeline job succeeds.

To require the pipeline on your default branch:

1. In Azure DevOps, select **Project settings** > **Repositories**.
2. Search for and select your repository.
3. Select **Policies**.
4. Under **Branch Policies**, select your default branch, such as `main`.
5. Next to **Build validation**, click **+**.
6. Select the **Build pipeline** that runs the Endor Labs scan.
7. Under **Trigger**, choose **Automatic (whenever the source branch is updated)**.
8. Set **Policy requirement** to **Required**.
9. Click **Save**.

For more information, refer to [Set build validation](https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies#set-build-validation).