PR Quality Gates
Enforce quality standards on every pull request.
What quality gates do
When a developer opens or updates a pull request, Implera runs deterministic analysis on the PR branch and evaluates the score against your configured thresholds. If any enabled domain drops below its threshold, the PR check fails.
The developer sees exactly which domains failed and why. There is no ambiguity: each domain reports its current score alongside the required threshold so the team knows precisely what needs fixing before the PR can merge.
Setting up quality gates
Quality gates are configured per project. Follow these steps to enable them:
- Go to your project Settings page.
- Under PR Quality Gate, enable the toggle.
- Set a threshold (0–100) for each domain you want to enforce. Setting a domain to
0disables it. - Save your changes. The gate takes effect on the next PR event.
PR quality gates require the Pro plan. Free plan users can view analysis results but cannot enforce gates on pull requests.
GitHub App permissions
The Implera GitHub App needs Checks (read and write) and Pull Requests (read) permissions to post results on your PRs.
If you installed the GitHub App before enabling PR quality gates, you may need to approve the new permissions. Go to GitHub Settings > Applications, find Implera and accept the updated permission request.
What appears on the PR
When a quality gate runs, three things appear on the pull request:
- GitHub Check Run — a pass or fail status that blocks or allows merging depending on your branch protection rules.
- PR comment — a formatted score table showing each enabled domain, its score and whether it passed.
- Inline annotations — file-level annotations on the diff for security and accessibility findings, pinpointing the exact lines that need attention.
Example PR comment:
| Domain | Score | Threshold | Status |
|---|---|---|---|
| Security | 85 | 70 | Pass |
| Architecture | 72 | 60 | Pass |
| Maintainability | 78 | 60 | Pass |
Overall score: 78/100
Recommended thresholds
Start strict on the domains that matter most to your team and leave others disabled until you are ready. Here are sensible defaults for most projects:
| Domain | Threshold | Notes |
|---|---|---|
| Security | 70 | Catch regressions in secrets, auth and injection patterns. |
| Architecture | 60 | Flag structural drift and coupling issues early. |
| Maintainability | 60 | Prevent overly complex or deeply nested code from merging. |
| Testing | 0 | Disable until your project has meaningful test coverage. |
| Performance | 0 | Enable when performance monitoring is a priority. |
| Dependencies | 0 | Useful for larger projects with many third-party packages. |
| Accessibility | 0 | Enable once your team has accessibility guidelines in place. |
| Documentation | 0 | Best suited for open source or public-facing libraries. |
You can adjust thresholds at any time. Changes apply to the next PR event without requiring any code changes.
What's next
If you want to run quality checks in your CI pipeline rather than through the GitHub App, see the GitHub Action documentation. The Action reads thresholds from the same project settings, so your gates stay in sync.