# Diagnose missing SonarQube pull request decoration (no checks or comments on the PR)

Fix absent SonarQube PR decoration by classifying first: analysis not PR-scoped (auto-detection gaps, manual sonar.pullrequest.key/branch/base), invalid org/project ALM binding, edition limits on SonarQube Server, or missing SCM blame data — verified via the scanner log and ce.log.

Exact reference: {"kind":"skill_version","skill_id":"skl_LzMqe1js1VjjtsqMEHIwmg","version_id":"skv_thi928fMTC8flJM6lXughA"}

Applicability: [{"constraint":">=9.9, Developer Edition or above","technology":"SonarQube Server","version_scheme":"semver"},{"constraint":"all plans","technology":"SonarQube Cloud","version_scheme":"unknown"}]

# Diagnose missing SonarQube pull request decoration (no checks or comments on the PR)

Use this when the pipeline runs, the SonarQube analysis completes, and the quality
gate may even be green — but nothing appears on the pull request: no status check,
no inline comments, no summary. Classify first whether the analysis was even
PR-scoped, because "analysis ran as a branch" and "PR analysis ran but decoration
failed" have completely different fixes.

## 1. Was the analysis PR-scoped at all?

Search the scanner log for the PR detection line:

```
INFO: Load project pull requests
INFO: Pull request 42 for merge into main from feature/auth
```

- **These lines are present** — the scanner knew it was a PR. Skip to step 3.
- **Absent, and the analysis went to a branch instead** — auto-detection did not
  fire. The scanner auto-detects PR parameters only for matched CI/ALM pairs
  (GitHub Actions on a GitHub repo, Azure Pipelines on an Azure DevOps repo).
  Cross combinations — e.g. Azure Pipelines building a GitHub repo, or Jenkins —
  need the parameters passed explicitly:

```
-Dsonar.pullrequest.key=42
-Dsonar.pullrequest.branch=feature/auth
-Dsonar.pullrequest.base=main
```

  A "check stuck in Queued" on the PR is the same root cause seen from the other
  side: the report landed on a branch, so the PR check waits forever.

## 2. Edition check (SonarQube Server only)

Branch and pull request analysis on SonarQube Server require **Developer Edition
or above** — Community Build does not include them, and running the PR parameters
against it will not produce decoration no matter how the pipeline is configured.
(On SonarQube Cloud, PR decoration is available on all plans.) If you are on
Community Build and PR decoration is a requirement, the edition is the blocker,
not the configuration — confirm against your edition's documentation before
debugging further.

## 3. Check the ALM binding — the #1 cause per SonarSource's own guide

Decoration is driven server-side after the Compute Engine finishes, and it needs a
valid link between SonarQube and the DevOps platform at two levels:

- **SonarQube Cloud, organization level:** an organization admin opens
  **Administration > Organization Settings > Organization binding** and confirms
  the binding to GitHub / Azure DevOps / GitLab / Bitbucket is present and valid.
- **SonarQube Cloud, project level:** a project admin opens the project's
  **Administration > General Settings > Repository binding** and confirms the
  correct repository is selected.
- **SonarQube Server:** **Administration > Configuration > DevOps Platform
  Integrations** holds the GitHub App / PAT / token configuration, and each
  project's **Project Settings > General Settings > Pull Request Decoration**
  selects which integration it uses. On GitHub the app must be installed on the
  organization or repository; a green-looking config with the app not installed
  decorates nothing.

If the binding was recently re-created (app reinstalled, token rotated), re-run an
analysis afterward — decoration only fires on analyses that complete after the
binding is valid.

## 4. Read the Compute Engine log

Open the project's background task (Administration > Projects > Background Tasks,
or the task link on the analysis) and check `ce.log`:

```
Pull Request Decoration | status=SUCCESS | time=12ms
```

- **Step missing entirely** — the analysis was not recognized as a PR (back to
  step 1) or no binding is configured (step 3).
- **Step present with an error** — the error names the cause directly (bad
  credentials on the GitHub App, repository not found, API rate limit).
- **Step present, SUCCESS, but nothing on the PR** — the decoration went to the
  wrong target: verify the repository binding points at the same repo the PR
  lives in (forks and renamed repos are the usual culprits).

Raise the log level temporarily under **Administration > System** (set to DEBUG),
re-run one PR analysis, then set it back to INFO — the decoration step logs the
exact API calls and their responses at DEBUG.

## 5. SCM data: new-code detection needs blame

PR decoration annotates *changed* lines, and changed lines come from git blame.
Two silent killers:

- **Shallow clones.** The scanner logs `Shallow clone detected, no blame
  information will be provided`. Some features that rely on blame degrade. Use a
  full clone (`fetch-depth: 0` on `actions/checkout`) for the analysis job.
- **`sonar.scm.disabled=true`.** Disabling the SCM sensor removes blame data and
  breaks new-code detection for PRs. Leave SCM enabled unless you have a
  documented reason not to.

You will also see `WARN: Missing blame information for the following files` for
files the scanner could not blame — if every changed file is listed there, the
PR summary will be empty even with perfect binding.

## 6. Checklist for the undecorated PR

1. Scanner log shows `Pull request [N] for merge into [base]`; if not, pass
   `sonar.pullrequest.key/branch/base` explicitly (required for cross CI/ALM
   combos).
2. Edition supports PR analysis (Developer Edition+ on Server).
3. Organization binding valid (Cloud) or DevOps Platform Integration configured
   (Server), and the project bound to the correct repository.
4. `ce.log` shows the Pull Request Decoration step; DEBUG it once if the cause is
   unclear.
5. Full git history available in the analysis job; `sonar.scm.disabled` not set.
6. On GitHub, expect one check named `SonarQube Code Analysis` per project —
   with monorepo multi-project setups, check the right project's check.


## Supporting basis and limitations

Built from SonarSource's official community guide 'Troubleshooting Missing Pull Request Decoration in SonarQube Cloud' (org/project binding as the #1 cause), the PR auto-detection support-matrix thread (Azure Pipelines on GitHub repos needs manual parameters), and ce.log decoration-step diagnostics.

## Change and rationale

New skill: diagnose missing SonarQube pull request decoration.

PR decoration silently missing is a high-friction failure: the pipeline is green, the analysis exists, but nothing lands on the PR. The causes (PR auto-detection only for matched CI/ALM pairs, org/project binding as the #1 cause per SonarSource's own guide, Developer Edition requirement on Server, shallow clones killing blame) are each checkable from logs, so a decision procedure beats generic setup docs.