Overview
A quality gate is the policy a scan must pass. Each condition compares one measured metric against a threshold, and a scan passes only when every condition passes. Attaching a gate to a project turns each scan into a clear ship/no-ship decision and feeds the Dashboard's Failed gates card. This article shows how to set and tune a project's gate policy.
Where the gate lives
A gate policy is attached to a project. If a project has no custom policy, StretchDev applies the default gate, so every scan still gets a Pass/Fail result. You set a custom policy when creating or editing a project.
Define a gate
1. Open the Projects tab and create or edit a project.
2. In the Quality gate field, define your conditions. Each condition names a metric, a comparison, and a threshold. Typical conditions include:
- Security rating must be A.
- Reliability rating at least B.
- Maintainability rating at least B.
- Duplication under 5%.
3. Save the project. From then on, every new scan is evaluated against this policy, and the scan's result shows Pass or Fail with the specific conditions that failed.
Preview before you commit
Before making a policy stricter across an active project, preview it against the project's latest stored scan on the Quality tab. StretchDev re-evaluates the new policy against the most recent metrics — without writing a new scan — and shows exactly which conditions would pass and fail. This tells you how many current scans your change would start failing, so a policy change is never a surprise. (See Previewing analysis and gates without a new scan.)
Example
The Orders Service handles payments, so you want a strict gate:
- Security rating = A
- Reliability rating ≥ B
- Duplication < 4%
You attach that policy and preview it against the latest scan, which has Security B and duplication 6%. The preview fails two conditions. Rather than ship a failing project, you fix the vulnerability and extract a duplicated module, re-scan, and the gate passes. Meanwhile a lower-stakes internal tool keeps the more relaxed default gate.
Tips
- Match the policy to the stakes. Payment, auth, and data-handling projects deserve stricter gates than internal tooling.
- Start realistic, tighten over time. Set a gate your team can pass today, then raise the bar as ratings improve.
- Always preview a stricter policy against the latest scan before saving it, so you know the blast radius.
- Map conditions to levers: Security ↔ vulnerabilities, Reliability ↔ bugs, Maintainability ↔ code smells and duplication.
Troubleshooting
- Every scan fails the gate. The policy is stricter than the code's current state. Preview against the latest scan, then either fix the code or relax the threshold.
- The gate never fails even on bad code. Your policy may be empty or only setting loose thresholds — add the conditions that matter to your team.
- A gate preview needs the engine. Previewing a gate against the latest metrics is a compute action; if it reports the engine is unavailable, ask an administrator to enable it. Reading a scan's already-stored gate result does not need the engine.
Was this helpful?
Help us improve this article
Use these controls to share whether this answer solved the issue. Feedback helps prioritize updates to StretchSuite Support.