Extra CODEOWNERS documentation¶
Your dependency automation already knows when a pull request is routine.
Stampbot may approve a trusted
uv.lock update after its own rules pass, but GitHub's native code-owner
setting still expects a person or team from CODEOWNERS.
Extra CODEOWNERS publishes an alternative required check. It accepts a current-head approval from an appropriate human, or a current-head approval from an enrolled GitHub App when policy delegates that path and owner to the App. A regular pull request still goes to its human owners. The evaluator implements both paths, but the project has not recorded a dated live GitHub run of the App-review and required-check contract.
Pre-release: evaluate only in a disposable environment
Extra CODEOWNERS is not ready to enforce production merges. A public GitHub Container Registry (GHCR) preview exists, but it predates the current release controls and is not a supported deployable artifact. Don't deploy, mirror, or redistribute it. Read the current project status before you register or test the App.
Understand the boundary first¶
The existing CODEOWNERS file keeps its people and teams. Extra CODEOWNERS
adds two policy scopes:
- Organization policy enrolls Apps by immutable identity and names paths where App substitution is never accepted.
- Repository policy opts in one repository and delegates narrower paths, owner sets, and optional label restrictions.
The repository can't enroll a new App or weaken an organization guardrail. The native CODEOWNERS comparison walks through the complete decision and the GitHub rule it is meant to replace. The threat model covers the trust and failure boundaries.
Choose your route¶
Repository administrator evaluating the idea¶
Start with these pages, in order:
- Compare native CODEOWNERS with the extra check.
- Check what is implemented and what is still blocked.
- Run the first check in a disposable organization.
- Preflight the non-required evaluation beta.
- Exercise the replacement repository rule and its rollback.
The live GitHub contracts are not all proven. Keep GitHub's native Require review from Code Owners rule on production repositories.
Policy administrator¶
Use the configuration guide to enroll an App, delegate low-risk paths, and test the human-only boundary. The configuration reference lists every field, default, limit, and failure mode.
Developer testing the App¶
The first-check tutorial starts with a clean checkout and ends with a real Check Run on a disposable pull request. It uses a human approval first, so you can isolate the checker from the approving App.
If you already have a development service:
- register a GitHub App with the setup URL
- configure both policy scopes
- run the live GitHub contract fixture.
Operator reviewing a future deployment¶
There is no supported image, chart package, or production deployment today. The current source still defines useful contracts for review:
- prepare a future deployment
- upgrade, back up, and restore
- operate and recover
- review the architecture.
These pages describe the source and the intended operating boundary. They aren't a release or production-readiness claim.
Maintainer or contributor¶
The maintainer index collects release evidence, supply-chain controls, dependency review, and live-contract work. For local development and pull-request requirements, use the repository's contributor guide.
Look up exact behavior¶
Use reference pages when you need the contract rather than a walkthrough:
- checks and evaluation
- configuration
- command line
- GitHub permissions and webhook events
- HTTP API
- project status.
For a failed, pending, or missing Check Run, start with Troubleshoot a check. It follows the text shown in GitHub and tells you when an operator needs to intervene.
Get help¶
Use the repository's support policy for questions and operational incidents. Report vulnerabilities through the private security policy, not through a public issue.