Skip to main content
You can scan pull requests or merge requests using endorctl for GitHub, GitLab, and Bitbucket. The --pr flag runs the scan for the current commit and records the results as PR Runs that do not affect main branch monitoring scans and reports. Endor Labs stores PR and MR scan findings in PR Runs for three weeks, after which they are removed to accommodate new PR scans. Before you run PR scans, scan your baseline branch at least once so incremental PR scans have a baseline to compare against.

​
Scan PRs using endorctl

A PR scan command combines the following flags. The following sections explain how these flags work together. To go straight to the ready-to-run command, see Set up PR scans step by step.

​
Perform incremental PR scan

An incremental PR scan scans only the parts of the codebase and dependencies that have changed since the last full baseline scan.
  • Endor Labs identifies packages and dependencies in the PR and scans only those that changed relative to the baseline.
  • If no dependencies changed, the scan is skipped, and Endor Labs reports No changes found.
  • Incremental PR scans report only findings that involve dependencies the pull request changed and that do not exist in the baseline.
  • You can enable incremental PR scans using the --pr-incremental flag or the equivalent CI settings. This flag is also available for SAST incremental scans and Incremental secret scans.
You need to set a baseline for incremental PR scans so only findings new relative to that branch are reported. For GitHub App or GitLab App scans, or when PR comments are enabled, the baseline is detected automatically. Otherwise, pass --pr-baseline when you run the scan. See Set a default branch for how the default branch is chosen and used.
Baseline mismatch in PR scansIf a finding is fixed in the baseline by upgrading or downgrading a dependency and a PR still modifies that package, the finding can be reported as new. To mitigate this, rebase the PR with the latest baseline content and re-run the PR check.

​
Publish findings as PR comments

Endor Labs can post new findings as review comments on the pull request or merge request. Comments are posted according to your action policies. To publish comments:
  • Set --enable-pr-comments and --scm-pr-id so the scan posts comments to the right PR and infers the baseline from its merge target.
  • Authenticate with --scm-token or the ENDOR_SCAN_SCM_TOKEN environment variable.
  • Configure an action policy with Branch Type Pull Request so violations generate comments.
See Pull Request comments for app-based setup, the required action policy configuration, and comment templates.

​
Skip unaffected languages during incremental PR scans

When you combine --pr-incremental with --quick-scan, Endor Labs inspects the changed files in the pull request before resolving dependencies for each language. If the pull request contains no build file changes for a language, Endor Labs skips dependency resolution for that language entirely. This behavior is enabled by default for all supported languages and ecosystems in endorctl v1.7.1002 and later. The scan log records each skipped language.

​
Skip unaffected packages during incremental PR scans

When a pull request does change build files, Endor Labs can prune further and resolve dependencies only for the packages those files affect. This reduces incremental PR scan times in large repositories and monorepos. Endor Labs classifies each changed build file by its scope of impact. The following examples come from JVM projects, and every supported language or ecosystem has an equivalent set of build files:
  • A single package, such as gradle.lockfile.
  • A package and every package under it, such as a parent pom.xml, settings.gradle, or gradle.properties.
  • The entire repository, such as gradle-wrapper.properties, files under buildSrc or .mvn, and version catalogs like gradle/libs.versions.toml.
Packages that no changed file affects are not resolved again, and their results carry forward from the baseline scan. Endor Labs enables package-level skipping by default in the following endorctl versions. To turn off package-level skipping, set ENDOR_SCAN_INCREMENTAL_DEP_RES=false before you run the scan.

​
Troubleshoot incremental PR scan performance

If an incremental PR scan takes longer than expected or does not skip dependency resolution, do the following checks:
  1. Verify that endorctl is v1.7.1002 or later. Package-level skipping requires a later version, depending on your language or ecosystem. See Skip unaffected packages during incremental PR scans.
  2. Confirm that the scan sets both --pr-incremental and --quick-scan.
  3. Confirm that the scan is a pull request scan. Scans tagged merge-to-main resolve all dependencies.
  4. Check the scan log for Detected N changed files. An unexpectedly large count means the pull request diff could not be computed correctly.
  5. Look for skip confirmations in the scan log, such as Skip dependency resolution for 3/12 maven modules: No relevant changes detected.
  6. Check whether the pull request changes a root or parent build file. These changes affect every module in the repository, so Endor Labs resolves all of them even with package-level skipping turned on.

​
Maven dependency resolution on large projects

Maven dependency resolution can take a long time on projects with large or complex dependency trees, when a PR changes a root or parent build file. To reduce dependency resolution time in PR scans:
  • Confirm that --pr-incremental and --quick-scan are both set. Endor Labs skips dependency resolution for languages and packages that a pull request does not affect. See Skip unaffected packages during incremental PR scans.
  • For monorepos with 100 or more pom.xml files, set ENDOR_SCAN_MAVEN_PREPOP_CACHE=true in GitHub App or other hosted scans to pre-populate the Maven local cache in parallel before Endor Labs scans each module. This setting has no effect in CI-triggered or local endorctl scan runs. See Environment variables that affect scan behavior.

​
Set up PR scans step by step

Add the following flags to your scan command in order, and verify each step in your CI pipeline before adding the next.
1

Start with a PR scan

Run a PR scan on the current commit. Endor Labs records the results as a PR Run instead of a monitoring scan.
2

Scan only what changed

Add --pr-incremental and point --pr-baseline at the branch the PR merges into. The scan reports only findings that are new relative to the baseline.
3

Speed up the scan

Add --quick-scan to skip call graph generation and skip dependency resolution for languages and packages the PR does not affect.
4

Post findings as PR comments

Add --enable-pr-comments with --scm-pr-id and an SCM token. Remove --pr-baseline because the scan now infers the baseline from the merge target of the PR. This is the recommended command.
5

Block merges on findings

The scan reports findings and posts comments, but it does not block merges on its own. Pair the command with an action policy that breaks the build and a required status check on your target branch. See Block pull requests on findings.
6

Optional: Point to GitHub Enterprise Server

If your organization runs GitHub Enterprise Server, add --github-api-url with the API URL of your server.

​
Adjust the command for your setup

  • Run without PR comments: Stop after step 3. Keep --pr-baseline and do not set --enable-pr-comments or --scm-pr-id.
  • Include reachability analysis: Drop --quick-scan to resolve dependencies fully and generate call graphs. The scan takes longer, but findings include reachability information.