Documentation Index
Fetch the complete documentation index at: https://docs.codeant.ai/llms.txt
Use this file to discover all available pages before exploring further.
Overview
Most teams want to set baseline review rules, instructions, quality gates, and analysis filters once at the organization level — and then let individual repos override or extend them when they need to. Global Repo Configuration lets you do exactly that. You designate one repository in your org as the global config repo. Its.codeant/ directory is then merged into every other repo in the org at review time:
| File | Merged with |
|---|---|
.codeant/review.json | The repo’s own review.json rules |
.codeant/instructions.json | The repo’s own instructions.json instructions |
.codeant/quality_gates_conditions.json | The repo’s own quality gate conditions |
.codeant/configuration.json | The repo’s own analysis configuration (file filters etc.) |
- You manage company-wide standards in one PR-reviewed repo.
- New repos get those standards automatically — no copy-paste.
- A team that needs an exception just commits an override to their own
.codeant/.
How Merging Works
CodeAnt fetches the four files from the global repo using the same logic it uses for any other repo file (with caching), then merges each one into the repo currently being reviewed using the rules below. If the global repo is unset, unreachable, or missing one of the files, that file is skipped silently and the repo-level config is used as-is.review.json (rules)
Merged by id:
- Every rule in the repo’s local
review.jsonis kept as-is. - Each rule in the global
review.jsonis added only if no local rule has the sameid.
id locally — yours takes precedence. To remove a global rule for a single repo, define a local rule with the same id and an empty/no-op description.
Rules are also filtered by scope — only rules with "pr" in their scope apply during PR review.
instructions.json
Merged by id, exactly like review.json rules. Local instructions win over global instructions with the same id. Only instructions with "pr" in their scope apply during PR review.
quality_gates_conditions.json
Merged by metric — the same field name used by the repository configuration:
- Every condition in the repo’s local file is kept.
- Each condition in the global file is added only if no local condition is defined for the same metric.
sast_rating: LESS_THAN B and a repo’s local file overrides it with sast_rating: LESS_THAN A, the repo’s stricter A-or-better requirement wins. If a repo doesn’t define sast_rating at all, the global B-or-better requirement applies.
The repo’s enabled flag still takes full precedence:
- Local
enabled: falsedisables quality gates for the repo (global is ignored). - Local
enabled: trueactivates the merged condition set. - Local
enabled: nullor no local file → global conditions apply unmodified.
configuration.json
Currently this is used for include/exclude file filters. The repo and global patterns are concatenated (comma-separated) — the global filters extend the repo’s filters, they never replace them.
- If only the global file defines a filter → the global filter applies.
- If only the repo defines a filter → the repo filter applies.
- If both define a filter → the patterns are joined with a comma (
repo_patterns,global_patterns) and both apply.
Configuring the Global Repo
Navigate to Settings → AI Code Review at app.codeant.ai/settings/prconfsettings. Scroll to the Global Repo Configuration section, click Configure Global Repo, and:- Repository — pick any repo in your org. Most teams use a dedicated
codeant-configrepo or piggyback on an existing platform/infra repo. - Branch — leave blank to use the default branch, or pick a specific branch (useful while you’re iterating).
- Click Save.
Only org admins can configure the global repo. Other roles see the panel as read-only.
Setting It Up
1. Create the global config repo
Pick (or create) a repo in your org to act as the source of truth. Add a.codeant/ directory and the four files you care about. Anything you don’t need can be omitted — only files that exist are fetched.
2. Author org-wide defaults
Examples:review.json — enforce a no-console.log rule org-wide:
instructions.json — set a Spanish-language preference for one team’s repos:
quality_gates_conditions.json — enforce baseline security standards:
configuration.json — exclude generated files from analysis everywhere:
3. Point CodeAnt at the repo
In the Global Repo Configuration panel, select the repo and (optionally) the branch. From the next review onwards, every other repo in the org gets these defaults merged in.4. Override per repo where needed
In any individual repo, drop a.codeant/ directory and define overrides using the same id (for rules/instructions) or same metric (for quality gates). Repo-level values win.
Best Practices
- Treat the global repo like any other repo. Require code review on changes — this is your org-wide review policy.
- Use stable, descriptive
ids for rules and instructions so individual repos can override them by name. - Pin to a branch while iterating, then point at the default branch once you’re happy.
- Keep the global config minimal. Anything that’s truly universal goes here. Anything team-specific belongs in the team’s own repo.
- Document what’s enforced. A
README.mdin the global config repo explaining each rule and condition saves a lot of “why did this fail my PR?” questions.
Related
- Code Review Rules — repo-level
review.jsonformat - Instructions — repo-level
instructions.jsonformat - Quality Gates Repository Configuration — repo-level
quality_gates_conditions.jsonformat