Detect manifest changes across the whole pull request range, and fix full-scan reporting

[lelia]

Summary

Four fixes to how a pull request scan decides whether to compare, and what it reports when it does not.

Changed-file detection covers the whole range. Detection read a full comparison range only inside a recognized GitHub, GitLab, Bitbucket, or Buildkite pull request. Every other run fell through to git show HEAD and saw the tip commit alone, which made dependency gating depend on commit ordering: a pull request whose manifest changed in an earlier commit, followed by a source-only commit, looked like a source-only change. The comparison was abandoned for a full scan, blocking was suppressed, and the run exited 0. --base-commit-sha now also sets the range detection reads, reusing the same range detection the recognized providers already use.

A full scan no longer reports its findings as new. A run with no baseline suppresses blocking, because nothing can be attributed to the change. With an alert-bearing output format enabled the scan still carries every finding in the repository, and the console summary labeled those NEW and their link Diff Url — so it reported blocking issues while exiting 0, which reads as gating that silently failed rather than gating that correctly did not apply.

Removed packages no longer carry a doubled namespace. update_package_values already prefixes a namespaced purl, so prefixing it again while collecting removed artifacts produced com.example/widget@1.0.0com.example/com.example/widget@1.0.0 on every removed or replaced row of the dependency overview comment.

--ignore-commit-files is described by what it does. The CLI reference called it a way to force a full scan in four places, and --help said only "Ignore commit files". The flag forces a comparison. "Full scan" carries two meanings here — the set of files scanned, where the documentation was right, and the scan mode, where it stated the opposite — so anyone looking for a way to run a comparison when the changed-file check would skip one would rule out the only flag that does it.

Why these belong together

The first two are the same code path from both ends: when the no-supported-manifest fallback fires, and what it reports once it has. The documentation fix answers the question that path raises for anyone hitting it. The purl fix is a two-line deletion that would otherwise wait on its own review cycle.

Decisions worth confirming

• An explicit base commit wins over CI environment inference. Passing --base-commit-sha states the range outright, so it is honored ahead of anything inferred from the environment. A test pins the precedence with the two sources deliberately disagreeing.
• An unresolvable base commit warns rather than failing. The run continues down the existing ladder, but silently narrowing the comparison to one commit is the defect this fixes, so it says so. A base commit absent from a shallow checkout is fetched first; git fetch origin <sha> needs uploadpack.allowReachableSHA1InWant on the server, and the warning points at deepening the clone.
• The alert list itself is unchanged. Only the console labels move. SARIF and JSON output read new_alerts, and renaming their fields would break consumers.

Testing

• pytest -q tests/unit tests/core — 726 passed, 0 failed. A bare pytest honors testpaths = tests/unit and skips tests/core; both directories are run explicitly here, as CI does.
• ruff check socketsecurity tests — clean.
• uv lock --check and git diff --check — clean.
• 12 new tests. Detection coverage builds real repositories with git init: a manifest changed mid-range under a source-only commit, precedence against CI variables, and an unresolvable base. The purl test was confirmed to fail without its fix, emitting the doubled string above.

Notes for review

• uv.lock carries only the version line. Regenerating it locally rewrote nine dependency markers with unrelated emscripten conditions, which appears to be a uv version difference rather than anything this branch needs.
• Each concern is its own commit, so any one can be reverted alone.

---

Fixes: CE-471, CE-472, CE-480

---

Note

Medium Risk
Changes core git changed-file logic and when diff vs full-scan paths run, which can alter CI gating behavior; output labeling changes are console-only but affect how operators interpret exit codes.

Overview
Release 2.10.0 tightens when PR-style comparisons run and how full-scan output reads in CI.

Changed-file detection now honors the full --base-commit-sha..HEAD range (explicit base wins over CI inference, uses .. instead of merge-base ...). Outside recognized PR/MR CI, runs no longer only inspect the tip commit—so a manifest change in an earlier commit still triggers a comparison. Unresolvable base SHAs emit a warning instead of silently narrowing to one commit.

Full-scan console summaries stop labeling repository-wide findings as NEW, use Report Url, and explain that counts do not affect exit code when there is no baseline.

Dependency diff comments no longer double-prefix namespaces on removed/replaced package purls.

Docs and --help for --ignore-commit-files now describe forcing a comparison over all manifests, not a “full scan” in the scan-mode sense.

^{Reviewed by Cursor Bugbot for commit 7fddc19. Configure here.}

[cursor]

Stale Bugbot comment from a previous run.

[lelia]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 7fddc19. Configure here.}