## TL;DR For "WARN: Missing blame information for the following files": use a full clone (fetch-depth: 0 on actions/checkout) for the analysis job. - sonar.scm.disabled=true. 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. Skip to step 3. - Absent, and the analysis went to a branch instead, auto-detection did not fire. ```text WARN: Missing blame information for the following files ``` ## When to use You are seeing this: 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. Use this skill when you run into "Diagnose missing SonarQube pull request decoration (no checks or comments on the PR)". ## When not to use If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit. ## Versions No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed. 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 [your value] -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.