> ## 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.

# Global Repo Configuration

> Maintain a single org-wide source of truth for .codeant/ config and merge it into every repo automatically

## 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.) |

**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](/pull_request/quality_gates/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](https://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.

<Note>
  Only **org admins** can configure the global repo. Other roles see the panel as read-only.
</Note>

## 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:**

```json theme={null}
{
    "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:**

```json theme={null}
{
    "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:**

```json theme={null}
{
    "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:**

```json theme={null}
{
    "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 `id`s** 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.

## Related

* [Code Review Rules](/pull_request/customize/rules) — repo-level `review.json` format
* [Instructions](/pull_request/customize/instructions) — repo-level `instructions.json` format
* [Quality Gates Repository Configuration](/pull_request/quality_gates/repository_configuration) — repo-level `quality_gates_conditions.json` format