Skip to main content

GitHub Now Shows Code Coverage Directly in PRs — No Third-Party App Needed 🎯

· 5 min read
Gergely Sipos
Gergely Sipos
Frontend Architect

GitHub shipped native code coverage in Pull Requests as a public preview. You get line-level annotations in the diff view, coverage deltas in the conversation tab, and enforcement via repository rulesets — all without installing Codecov, Coveralls, or any external app. No tokens, no OAuth grants, no third-party data access.

This continues a familiar pattern: GitHub absorbing common CI/CD tooling into the platform itself. Dependabot replaced Greenkeeper. Code scanning absorbed LGTM. Secret scanning eliminated dedicated tools. Now coverage display and gating joins the list.

Full details in the GitHub Changelog announcement.

What It Does​

The feature adds three things to the PR experience:

  • Line-level coverage annotations — Changed lines in the diff view show green (covered) or red (uncovered) indicators. You see exactly which new code your tests exercise and which they don't.
  • Coverage summary widget — The PR conversation tab shows aggregate coverage for the changed files: lines covered, lines missed, percentage.
  • Coverage delta — Shows whether this PR improves or worsens overall project coverage compared to the base branch. A clear "+2.3%" or "-0.8%" signal.

An important distinction: this is display and enforcement, not a test runner. GitHub doesn't run your tests or generate coverage data. Your CI workflow produces the coverage report; GitHub consumes and renders it.

How It Works​

The flow is straightforward:

  1. Your GitHub Actions workflow runs tests and generates coverage in a standard format.
  2. A GitHub-provided upload action sends the coverage data to the platform.
  3. GitHub parses the report and annotates the PR.

Supported formats: LCOV, Cobertura XML, and JaCoCo XML. These cover the vast majority of test frameworks across JavaScript, Java, Python, Go, and .NET ecosystems.

Here's a conceptual workflow for a Node.js project using Vitest:

.github/workflows/coverage.yml
name: Test & Coverage
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npx vitest --coverage --coverage.reporter=lcov
      - uses: actions/upload-coverage@v1
        with:
          files: coverage/lcov.info
note

This feature is in public preview. The exact action name (actions/upload-coverage) and its API surface may evolve before GA. Check the GitHub documentation for the latest syntax.

Enforcement via Repository Rulesets​

Display is useful. Enforcement is where this becomes genuinely valuable.

Coverage thresholds can be configured through repository rulesets (the successor to branch protection rules). You can define rules like:

  • Block merge if overall coverage drops below a threshold (e.g., 80%)
  • Block merge if the coverage delta is negative (no PR may reduce coverage)
  • Require coverage data to be present before merge is allowed

This shifts coverage from "informational comment that everyone ignores after week two" to an actual gate. Teams that struggled to maintain coverage discipline with advisory-only tools now have platform-level enforcement with zero integration overhead.

How This Compares​

AspectGitHub NativeCodecov / Coveralls
Data stays within GitHub✅❌ (third-party)
Requires app install / tokens❌✅
UI integrationNative diff annotationsPR comment + external dashboard
Historical trends / dashboardsNot yet (preview)Yes
CostFree (included)Free tier + paid plans

The practical takeaway: for teams that want "block PR if coverage drops," this removes an entire integration from your stack. One fewer OAuth app, one fewer vendor security review, one fewer thing to debug when the coverage comment stops showing up.

Power users wanting historical trend analysis, badge generation, monorepo per-package reports, or Slack notifications will likely still want dedicated tools. But for the 80% use case — see coverage in the PR, enforce a threshold — the native solution is sufficient and simpler.

Limitations (Public Preview)​

caution

This is a public preview with notable constraints:

  • GitHub.com only — No GitHub Enterprise Server support initially.
  • No dashboards or trend views — You can't see historical coverage graphs or project-wide heatmaps. It's purely per-PR.
  • No badge generation — If you use coverage badges in your README, you'll still need an external service.
  • API surface may change — The upload action and its parameters are not yet stable. Expect breaking changes before GA.
  • Limited format support — Three formats cover most cases, but niche tools may not output compatible reports without conversion.

What This Means for Aliz Projects​

Our stack is already well-positioned for this. Vitest outputs LCOV natively — it's one flag (--coverage --coverage.reporter=lcov). Most of our projects already generate coverage reports in CI; we just haven't been uploading them to a display layer.

Adoption path:

  1. Add the upload step to existing test workflows — one additional step in your YAML.
  2. Enable rulesets on the repository to enforce your team's coverage threshold.
  3. Remove Codecov/Coveralls if you were using them purely for PR annotations and don't need trend dashboards.

We recommend trying this on new repositories or lower-traffic repos first. Once the feature reaches GA and the API stabilizes, it's a natural fit for our standard CI template.

See our Testing Strategy docs for details on our Vitest + Playwright setup and how coverage generation fits into the broader testing workflow.

Further Reading​