GitHub CI Passed, but Where Is the Coverage Report?
The tests wrote a coverage file and the upload step turned green, but the pull request shows no report. Where did the coverage go?
- A successful GitHub Code Quality upload step can mean the upload was skipped because no PR exists.
- A push-only workflow needs another push after the PR opens; a pull_request trigger can run when it opens.
- Read the upload notice and step summary before treating a green check as stored coverage.
A green upload step can be an intentional skip
If a non-default branch has no open pull request, GitHub Code Quality can finish the coverage step successfully without sending a report. The October 1 change replaces a CI failure with a notice and step summary explaining the skip.
Check that the workflow uses actions/upload-code-coverage. This is a change to GitHub’s built-in coverage uploader, not a general rule for Codecov or Coveralls. Tests earlier in the same job may still have run and produced a file.
Opening a PR does not trigger a push-only workflow
The workflow strategy guide distinguishes these events. Creating a PR does not restart an earlier skipped upload.
| Push-only workflow | Coverage behavior |
|---|---|
| Push a branch with no open PR | Skip the upload successfully. |
| Open its PR without another push | No new push-triggered run. |
| Push again with an open PR | Find the associated PR and upload. |
| Push to the default branch | Use the default-branch upload path. |
These are routing rules. Permissions and a valid report are still required.
Use a PR trigger when the report should appear immediately
GitHub documents this event configuration for PRs and default-branch pushes. It is a fragment to adapt, not a complete workflow:
on:
pull_request:
push:
branches: [main]Replace main with the actual default branch. Keep the steps that generate and upload coverage. The setup guide explains that default-branch coverage supplies the comparison baseline.
Broad push and PR triggers can run twice for one PR commit. If tests must also run before a PR exists, decide their trigger separately from the upload: skipping an entire job skips its tests too.
An open PR does not rule out other skips
The action README requires code-quality: write. Discovering a PR for a push also needs pull-requests: read and gh on the runner.
Fork PRs and merge queue runs are skipped. Multiple PRs from one branch can also produce a skip if there is no unique default-branch target. Separately, fail-on-error: false allows an upload error to leave the step green.
The October change covers Team and Enterprise Cloud, including data residency, rather than Enterprise Server. Start with the action, event, associated PR, and notice. That sequence tells you whether to change a trigger or investigate an upload failure.