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?

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

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

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

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” 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.

Will this have any special pricing for opensource projects

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.

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 @… '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!

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?

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).

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?

In addition to the previous feedback, it would be valuable to have a summarized coverage view that works well for monorepos.

For example, being able to see coverage per repository, but also per project/package/app within the repo, would make the data much more actionable. Ideally, this could be exposed in an easy-to-consume way, such as coverage badges, a repository-level summary, PR annotations, or a simple dashboard/view that shows the current coverage state and trends.

This is especially important for larger monorepos where a single repository-level coverage number is often too broad and does not reflect the reality of individual projects inside the repo.

👋🏻 On Homebrew/brew#22471 (comment) I saw some unexpected behaviour with the first few edits of the coverage comment saying that, among others, a file cask/info.rb that I'd not touched in the PR was at -96% coverage compared to main. When the tests finished running, and the full coverage report was generated, the comment was edited to (correctly) say that there were no coverage changes compared to main.

Excuse the solutionizing, but maybe it should only detect and post the comment once the CI jobs are complete to avoid misleading reports?

This is great! Are there any plans to show the coverage percentage for changed code in the pull request? For example, if you introduce a new function that has full coverage, it would show 100% coverage for the pull request? This would be great in order to support rules which required X% of new code coverage before merging.

Feature looks pretty good so far from what I've seen, but the truncation on the filenames in the code coverage overview seems a little excessive?

I can't seem to enable this on a public repository that is not part of an Enterprise. Will Code Quality, including this feature, be made available for personal public repositories?

Honestly, this is the completely wrong way to go about it. You are forcing a UI upon your users and the UI is simplistic to use a polite term. ReportGenerator (.NET based if that earns a couple points towards getting the right thing implemented), is one of the best coverage report UIs out there. You should be allowing us to deploy a "site" and provide a link to that site. Gitlab does this.

Where you may want to focus on UI implementation, is representing coverage in the the diff. Again, Gitlab does this. However, with AI generating 50 file diffs in a day, and manually inspecting code diffs potentially being a an outgoing thing, I could totally understand Microsoft not wanting to dedicate resources to this. Yet, Microsoft should have nearly unlimited access to AI, so implementing
coverage indications in a diff view should just happen.

I really like the code coverage feature, and the setup process is straightforward. I don't think we need the other features under Code Quality at the moment, although that may be partly because Elixir isn't supported.

I would prefer coverage checks to run as part of the PR process so we can use GitHub's branch protection rules to prevent merges when coverage requirements are not met. In previous projects, I've typically required the patch coverage to stay the same or improve, while overall project coverage is used primarily for monitoring purposes.

This approach makes code coverage more than just a metric, it becomes an actionable quality gate that helps maintain standards over time.