# Change Analysis

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-4f34e6e093e2ab2ef49c2451444749e0e840dbe9%2Finspect-change-analysis-pr.png?alt=media" alt="Change Analysis page"><figcaption><p>Change Analysis showing PR results with linter badges for Duplicates, Compliance, Architecture, and Code Analyzer</p></figcaption></figure>

Change Analysis automatically reviews every pull request for code quality issues before it is merged. It runs four linters against the PR diff — not the entire repository — so results are focused on what actually changed.

## What gets checked

Each PR is analyzed by four linters. Results appear as colored badges on each PR row — green for pass, orange for warnings, red for failures.

### Duplicates

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-3ca3508f23b586dde152435817f11cd47364b973%2Finspect-duplicate-analysis-report.png?alt=media" alt="Duplicate Analysis Report"><figcaption><p>Duplicate Analysis showing aliased package detection with file locations</p></figcaption></figure>

Detects duplicate metadata components across your packages. For example, if the same CustomLabel appears in multiple packages, the Duplicates linter flags it with the exact file paths. This prevents conflicts during deployment where one package's version of a component overwrites another.

### Compliance

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-39b94a3b946d278641ea97c5375632766a204aa9%2Finspect-compliance-check.png?alt=media" alt="Compliance Check Results"><figcaption><p>Compliance Check showing rules checked, violations found, and specific warnings with file locations and rule details</p></figcaption></figure>

Checks your changes against a set of compliance rules. The report shows how many rules were checked, how many violations were found, and the specific warnings with file locations and rule descriptions. For example, flagging `System.debug` statements that should be removed before production.

### Code Analyzer

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-ac2afc97aee069c85b446569b52c072b22fdcc4f%2Finspect-code-analyzer.png?alt=media" alt="Code Analyzer Results"><figcaption><p>Code Analyzer results showing engine details, rules checked, issues found, and specific notes with file locations</p></figcaption></figure>

Runs Salesforce Code Analyzer (PMD and other engines) against the changed files. Results are presented in SARIF format with the engine used, rules checked, files analyzed, execution time, and specific issues with file locations and line numbers.

### Architecture

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-58ffc71cbc40c3a9a74fa7b762999667af7fde98%2Finspect-architecture-analysis.png?alt=media" alt="Architecture Analysis Results"><figcaption><p>Architecture Analysis showing AI-powered insights about coupling, dependency concerns, and design issues</p></figcaption></figure>

AI-powered analysis that evaluates the architectural impact of your changes. It identifies concerns like implicit coupling between packages, dependency violations, backwards compatibility risks, and design issues. Each insight includes the specific files involved and an explanation of why it matters.

## How it works

Change Analysis is triggered automatically when a PR is opened or updated. codev's workflow engine:

1. Clones the repository at the merge ref
2. Computes the diff between the PR and the base branch
3. Runs each linter against only the changed files
4. Publishes results to the server and creates a check run on the PR in GitHub

The whole process typically completes in under a minute.

## Configuring analysis

Click **Workflow Settings** on the Change Analysis page to enable or disable the PR analysis workflow.

You can also configure which linters are active and which should cause a PR check to fail by adding configuration files to your repository under the `config/` directory.

### Configuration files

All configuration files live in your repository root under `config/`. If a file is absent, the linter falls back to safe defaults.

| File                           | Purpose                                               |
| ------------------------------ | ----------------------------------------------------- |
| `config/analyze.yaml`          | Orchestration: which linters run, what causes failure |
| `config/compliance-rules.yaml` | Rules for the compliance linter                       |
| `config/code-analyzer.yml`     | Config for Salesforce Code Analyzer (PMD/ESLint/CPD)  |
| `config/ai-assist.yaml`        | Config for the AI architecture linter                 |
| `config/duplicates.yaml`       | Exclusion config for the duplicates linter            |

### Orchestration — `config/analyze.yaml`

This file controls which linters run and which ones cause a PR check to fail. It supports per-branch overrides, so you can enforce stricter rules on release branches while keeping feature branches lenient.

```yaml
# config/analyze.yaml
excludeLinters:
  - architecture

failOn:
  - compliance
  - code-analyzer

branchRules:
  - pattern: "release/*"
    failOn:
      - compliance
      - code-analyzer
      - duplicates
  - pattern: "main"
    failOn:
      - compliance
      - code-analyzer
```

When `changeSignificanceEnabled` is set to `true`, the architecture linter skips PRs whose diffs are below the significance thresholds defined in `ai-assist.yaml`. This saves AI API costs for trivial changes.

### Config priority

The analyzer resolves its orchestration config in this order:

1. **CLI flags** — highest priority
2. **`config/analyze.yaml`** — local file in the repo
3. **Server project config** — fallback when no local file exists (configured in codev under project settings)
4. **Defaults** — all linters enabled, none fail the check

For detailed configuration of each linter, see the sfp documentation:

* [Compliance Check](https://github.com/flxbl-io/docs/blob/main/sfp/analysing-a-project/compliance-check.md)
* [Duplicate Check](https://github.com/flxbl-io/docs/blob/main/sfp/analysing-a-project/duplicate-check.md)
* [AI Assisted Architecture Analysis](https://github.com/flxbl-io/docs/blob/main/sfp/analysing-a-project/ai-pr-linter.md)

## Viewing results

Click any PR row to see the full analysis detail. The left sidebar shows PR info (branch, target, commit) and linter result badges. The main content area has tabs for each linter — click through to see the specific findings.

The **Run History** section at the bottom of the sidebar shows previous analysis runs for the same PR, so you can see if issues were introduced or fixed across commits.