Running Scans and Reviewing Issues

Overview

A scan is one analysis pass over a project's source. StretchDev reads the files you supply as text — it never executes them — measures them, evaluates your quality gate, and stores the result: three ratings, a duplication percentage, a pass/fail gate outcome, and a full list of issues. This article covers running a scan and reading what comes back.

Run a scan

1. Open the Projects tab and find the project you want to analyze.
2. Click Run on its row.
3. Provide the scan inputs:
- File path — the path of the file being analyzed, for example src/charge.js.
- Source text — the actual code to analyze. StretchDev grades exactly the text you provide.
- Branch — defaults to the project's default branch.
- Commit SHA (optional) — record which commit this scan represents.
4. Click Run scan. StretchDev analyzes the file, evaluates the project's gate, and records a new scan with a key like scan-7b3c1a9f2d40.

You can supply more than one file in a single scan; the result aggregates ratings and issues across everything you submit.

Note: Running a new scan requires the analysis engine to be enabled. If you see "StretchDev engine is not enabled," an administrator needs to turn it on — see the FAQ.

Read the scan result

Open the Scans tab (or click Scans on a project row) and select a run. Each scan shows:

• Ratings — Maintainability, Reliability, and Security, each A (best) through E (worst).
• Duplication — the percentage of duplicated code detected.
• Gate result — Pass or Fail against the project's quality gate.
• Issue count — the total number of findings.
• Issue table — every finding, sorted most-severe first.

Understand issues

Every issue carries:

• Type — bug (something that will misbehave), code_smell (maintainability problem), or vulnerability (a security weakness).
• Severity — blocker, critical, major, minor, or info, listed from most to least serious.
• File and line — exactly where the finding is.
• Rule — the check that fired.
• Message — a plain-language description of the problem.

The issue table is ordered by severity — blocker at the top, info at the bottom — then by file and line, so the most urgent findings are always first. You can filter the list by a single severity to focus, for example, only on critical findings.

Example

You run a scan on src/charge.js for the Billing API project. The result:

The issue table leads with a critical vulnerability on src/charge.js:42 ("user input concatenated into a query"), then a major bug at line 88, then three minor code smells. You fix the vulnerability first, re-run the scan, and watch the Security rating climb and the gate flip to Pass.

Tips

• Fix top-down: blocker and critical findings first, then work down the table.
• Filter by vulnerability type to build a security-only worklist that ties back to the Dashboard's Open vulnerabilities card.
• Re-run a scan after each fix to confirm the rating and gate actually improved.
• Record the commit SHA so each scan is traceable to a specific point in history.

Troubleshooting

• "Provide files[] to scan." No source was supplied. Add at least one file path and its text, then run again.
• "StretchDev engine is not enabled." New scans need the engine turned on by an administrator. Existing scans still display.
• "Scan not found." The scan key or ID doesn't match a scan in your organization; confirm the workspace and that it wasn't removed with its project.
• Issue list is empty but a rating dropped. Some ratings reflect metrics (like duplication) that don't always produce a line-level issue; check the duplication percentage and the rating breakdown.