Pull request checks
A pull request into the default branch of an added repository gets a GitHub check run named Depos allowlist. It reads the manifests of the pull request's head commit and evaluates them against the allowlist. Nothing about the pull request is stored in Depos; the result lives on GitHub.
When a check runs
- The repository is scanned, not archived, and covered by the check's scope.
- The pull request targets the repository's default branch.
- It is opened, reopened, receives new commits, or has its base branch changed to the default branch.
Re-run on GitHub runs the check again, for example after you add an allowlist entry.
The conclusion
Only a package the pull request adds can fail the check: a package that violates the policy in the head and is not used at all on the base branch.
| Conclusion | When |
|---|---|
| failure | The pull request adds a violation in an ecosystem set to Enforce. |
| neutral | It adds a violation only in Audit ecosystems; or it adds none, but the default branch already has violations; or no ecosystem it uses is audited; or the check could not finish. |
| success | No violations at all. |
Violations the default branch already has are listed in the check's details (up to 50), but never fail it. Each package links to its page in Depos.
When the check cannot finish — GitHub's rate limit, an outage — it completes as neutral, so an outage never blocks a merge.
Scope
Allowlist → Policy → Pull request checks decides which repositories get the check:
- All added repositories — the default;
- Selected repositories — only the ones you pick;
- Off — none.
Changing it needs an organization admin.
Blocking merges
Enforce makes the check fail; it is GitHub that blocks the merge. In the default branch's branch protection rule or ruleset, add Depos allowlist as a required status check. From then on a pull request that adds a denied or unlisted package in an Enforce ecosystem cannot be merged until the package is allowed or removed.