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?