Code coverage on pull requests is now in public preview 🚀

[ebndev]

Code coverage metrics are now in public preview for all GitHub Code Quality users on github.com.

You can now see an aggregate percent of code covered directly on pull requests, giving reviewers a clear signal to help evaluate test completeness before merging. With coverage context in the pull request experience, your team can make faster, higher-confidence review decisions without switching to a separate tool.

To get started, enable code coverage for your repository and upload a Cobertura report from your existing CI workflow using the upload-code-coverage action.

Permissions

GitHub Apps and Actions workflows require the new code-quality:write fine-grained permission to upload code coverage reports to GitHub.

Availability and pricing

GitHub Code Quality is available today for GitHub Enterprise Cloud and Team, but isn’t yet available on GitHub Enterprise Server. It’s free during the preview period.

Learn more

• Learn more about Code Coverage in documentation
• Read the GitHub Code Quality documentation

[davesmits]

Great addition! Although i would have expect to first see test results / code coverage results in a github action before getting results in a PR? is that something that is considered?

[AlonaHlobina]

Thanks for the feedback! No, currently we consider PRs as the main surface for this data and will follow up with the main branch coverage soon after; but we will not surface anything in actions.

[smlx]

Nice feature! Is it possible to see current coverage in the default branch?

[AlonaHlobina]

Currently the code coverage data can be only seen on PRs. We will follow up with the main branch coverage soon after.

[grahame-student]

And how much should we expect to be paying after the preview period?

[AlonaHlobina]

The feature is part of the Code Quality product and will be included in its price. However, we are still working on clarifying the pricing for the Code Quality product.

[timotheeguerin]

Are there plans to extend this to work with PRs from forks as well?

[AlonaHlobina]

Thank you for highlighting this! We are aware of this limitation and will keep it on our radar to prioritize in future updates based on feedback like yours.

[kurochan]

Thanks for shipping this preview. I ran into a confusing file-level summary with a Go workspace that uploads a Cobertura report generated from multiple Go modules. A concrete example is this PR: abema/crema#61

In the Cobertura XML, packages are distinct, e.g. github.com/abema/crema, github.com/abema/crema/ext/protobuf, and github.com/abema/crema/ext/ristretto. However, the PR “most impacted files 1�7 table appears to group entries only by the basename in filename. Several packages contain a file named cache.go, and the summary showed cache.go dropping from 100% to 99%, even though github.com/abema/crema/cache.go remained 100%; the uncovered line was actually in github.com/abema/crema/ext/protobuf/cache.go.

It would be helpful if the PR coverage UI disambiguated files by repo-relative path or package/module path when there are duplicate filenames. For example, showing cache.go as github.com/abema/crema/cache.go, github.com/abema/crema/ext/protobuf/cache.go, or at least ext/protobuf/cache.go would make the report much clearer. Otherwise reviewers may think the wrong file regressed.

[AlonaHlobina]

Thank you for the feedback! We'll definitely look into this and see how we can make it better.

[deftio]

Will this have any special pricing for opensource projects

[AlonaHlobina]

The feature is part of the Code Quality product and will be included in its price. However, we are still working on clarifying the pricing model including special pricing for open source projects.

[aaronsteers]

Very cool feature. Is there any plan to add inline coverage feedback (similar to toggling blame on and off) within the PR diff itself? I think one of the best uses of this deep integration is for the code reviewer to know "these lines are/aren't covered by tests" while they are doing their review.

[AlonaHlobina]

Hi there, thanks for sharing your feedback! This is definitely on our roadmap, and the team is looking forward to working on it in the near future.

[titan-ron]

We've been looking for this for a while - finally! 🎉

A few pieces of feedback from a first pass:

1. Color in the report. The current PR coverage tables are pretty monochrome. Some visual signal (green for covered lines/improvements, red for misses/regressions, maybe a small delta badge) would make it much easier to spot what actually matters at a glance.

2. Job summary in GitHub Actions. It would be great if actions/upload-code-coverage (or the API) emitted a $GITHUB_STEP_SUMMARY block with the totals and the most-impacted files, the same way actions/upload-artifact and friends do. Today, I have to click into the PR's coverage tab to see anything; a summary in the workflow run would close the loop and also make it visible on push runs that aren't tied to a PR.

3. First-class Monorepo support. Related to the thread above - in a Monorepo, it's common to have one report per project/package (or per language). Right now, each call to upload-code-coverage competes via label, and the PR UI groups by basename so collisions are easy (see @ 1�7 's cache.go example). It would be great to either:

   • allow multiple labeled reports to coexist cleanly and be shown side-by-side per project, and/or
   • accept a base-path / project input so the UI can disambiguate files by their repo-relative path instead of basename.

4. Drop (or auto-infer) the required language input. Cobertura reports already list file paths, and GitHub already knows each file's language via Linguist - having to hard-code a single language per upload is redundant and breaks down for polyglot projects (one report covering, say, TS + Go has no correct answer). Making it optional and inferring per-file from the repo would be a nice cleanup.

Thanks again for shipping the preview!

[AlonaHlobina]

Thank you for the feedback! We'll definitely look into this and see how we can make it better.

[thaJeztah]

We were not able to set up this feature due to the current limitations, but I noticed from an example posted by someone further up (abema/crema#61 (comment)) that the table also contains links to the PR branch; those tend to be removed after the PR is merged, so they're either broken after that happens, or point to an unrelated branch if the same branch name is used.

[thaJeztah]

Silly question; are there examples what the reports look like? I found an example posted by someone in this thread; abema/crema#61 (comment) which seems very limited and to be just a flat markdown table with percentages per package (no options to "drill down" the report to see coverage per line), or are more extended reports available elsewhere?

[AlonaHlobina]

Hi there,
You are entirely correct. Currently, we only display code coverage as a single percentage metric on the Pull Request. However, delivering a full report featuring line-by-line coverage is on our immediate roadmap, and we plan to begin working on it soon.

[thaJeztah]

Thanks; I'll keep my eyes peeled!

[thaJeztah]

We got excited when seeing this announcement, and were hoping this could replace uses of CodeCov to cut down our list of dependencies / dependency services.

Unfortunately, I don't think this feature will be useful to us in its current form.

• No native support for Golang's coverage reports; not ideal, but this would've been a hurdle we're willing to take
• No support for pull requests from forks; this excludes all projects I work on, as we require changes to be made through a pull request, and (for security and hygiene) do not want changes to be pushed to "upstream".
• No support for coverage on main branch (https://github.com/orgs/community/discussions/194833#discussioncomment-17063479); this would've been our "plan B" if PRs are not supported; if the feature could show coverage over time, it would've given insight what areas of our codebase could use more coverage (and could still give insight "after the fact" that we regressed in specific pull requests).

(Going slightly orthogonal, but hope it's useful nonetheless); what I'm looking for is for GitHub to provide reports over time; not just Code Coverage, but also (e.g.) test results, benchmark results.

• A pull request may change coverage, but there's usually some amount of noise, so changes below a certain threshold will be ignored.
• A pull request may impact performance, but by a very small margin.
• A test may fail on a pull request, but pass after re-running, so get dismissed as "random failure"
• A pull request may extend a test or introduce a new test, incrementing CI duration with a small amount of time.
• Binary sizes may have increased with a couple of kb due to a new import introduced in a PR.

These are all incremental, and often "marginal", changes, but they will accumulate over time. Tests may turn out to be flaky, we may have lost X% coverage in a package between two releases, a test may have become slow, and overall CI time increased with X minutes, and our binary sizes may have doubled.

Having reports on individual pull request is useful (but much already possible with custom actions generating a report); having dashboards and reports at the repository / branch level, over time, would be much more useful (and something GitHub may be best to provide).

[AlonaHlobina]

Thanks for the feedback, @thaJeztah! Your points are incredibly reasonable and helpful as we shape this feature.

To give you some context on our direction: our focus is building out dashboards and reporting capabilities at the repository and branch levels so teams can track their quality metrics over time. While we won't have support for forks right out of the gate, it is absolutely on our radar to tackle as a fast-follow phase.

Stay tuned for updates as we make progress!

[remcohaszing]

What’s the point of specifying the language? Code coverage may span multiple languages. Also, other code coverage integrations (CodeCov / GitLab) work without having to specify this.

[remcohaszing]

This is a really cool feature, probably one of the most obvious missing features in GitHub that I would expect from a git provider.

Please add a proper UI for this in merge requests and GitHub Actions. Code coverage is not a comment. Using comments for integrations are a bit of a hack. Have a look at GitLab and CodeCov for inspiration.

[cmtrounce]

Hi, been waiting for something like this so really glad to see the start of it 😀

Some repositories have a separate workflow for default branches and pull requests as they can be quite complicated and have therefore have dedicated flows.

Is this feature going to be compatible with repositories that have pull requests and default branches running separate workflows?

The picker in the repository settings only lets you select one workflow - which one should be selected?

[joshhale]

Thanks for the feedback Callum! 🙇

I'll answer your second question first 😄 For Code Coverage reporting to work fully, the only requirement is that you are uploading coverage information for the default branch and for pull requests, so we can post a comment on the PR with statistics for both. You can use any workflow you like. You can even use multiple workflows to upload coverage reports for different languages or subsets of the code. If you already have a CI workflow it'd be natural to tweak it so that while running the tests it also computes coverage and uses the upload-code-coverage action to upload them.

And for your first question the answer is yes, but for Code Coverage reporting to work you'll need to be uploading coherent coverage reports for the default branch and for PRs. If you only run certain tests on PRs, and only upload coverage reports for those on PRs then we'll show the coverage for the PR but we won't have a comparable baseline for the default branch. If you only upload coverage reports on the default branch then you won't see any comments on PRs. If you upload coverage reports from both PRs and the default branch then you'll get the full experience. There's no requirement for those to come from the same workflow, but if the coverage reports aren't computed in the same way it might look like your PR is adding/removing coverage relative to the default branch.