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