Skip to main content

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:
FileMerged with
.codeant/review.jsonThe repo’s own review.json rules
.codeant/instructions.jsonThe repo’s own instructions.json instructions
.codeant/quality_gates_conditions.jsonThe repo’s own quality gate conditions
.codeant/configuration.jsonThe repo’s own analysis configuration (file filters etc.)
Repo-level values always win. A repo can override any rule, instruction, quality gate, or filter from the global config simply by defining one with the same identity locally. This means:
  • 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.json is kept as-is.
  • Each rule in the global review.json is added only if no local rule has the same id.
To override a global rule, define a rule with the same 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.
So if your global config sets 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: false disables quality gates for the repo (global is ignored).
  • Local enabled: true activates the merged condition set.
  • Local enabled: null or 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:
  1. Repository — pick any repo in your org. Most teams use a dedicated codeant-config repo or piggyback on an existing platform/infra repo.
  2. Branch — leave blank to use the default branch, or pick a specific branch (useful while you’re iterating).
  3. Click Save.
You can edit or remove the global config repo at any time from the same panel.
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.
codeant-config/
└── .codeant/
    ├── review.json
    ├── instructions.json
    ├── quality_gates_conditions.json
    └── configuration.json

2. Author org-wide defaults

Examples: review.json — enforce a no-console.log rule org-wide:
{
    "rules": [
        {
            "id": "no-console-log",
            "description": "Do not use console.log in production code. Use the project's logger instead.",
            "files": ["src/**/*.{js,ts,jsx,tsx}", "!**/*.test.*"],
            "scope": ["ide", "pr"]
        }
    ]
}
instructions.json — set a Spanish-language preference for one team’s repos:
{
    "instructions": [
        {
            "id": "use-spanish-comments",
            "description": "Provide review comments and suggestions in Spanish.",
            "files": ["**/*.{js,ts}"],
            "scope": ["ide", "pr"]
        }
    ]
}
quality_gates_conditions.json — enforce baseline security standards:
{
    "quality_gate": {
        "enabled": true,
        "conditions": [
            {
                "metric": "secrets",
                "operator": "GREATER_THAN",
                "value": "0",
                "scope": ["commit", "pull_request"]
            },
            {
                "metric": "sast_rating",
                "operator": "LESS_THAN",
                "value": "B",
                "scope": ["pull_request"]
            }
        ]
    }
}
configuration.json — exclude generated files from analysis everywhere:
{
    "review_configuration": {
        "exclude": ["**/generated/**", "**/*.pb.go", "dist/**"]
    }
}

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.md in the global config repo explaining each rule and condition saves a lot of “why did this fail my PR?” questions.