GitHub stops missing pull-request numbers from failing coverage uploads

An expected missing context no longer becomes a failure

GitHub changed its upload-code-coverage action on October 1 so a push to a non-default branch without an open pull request skips the upload instead of failing CI. Previously, the coverage API needed a pull-request number that did not yet exist. The action now explains the skip in a notice and step summary. Default-branch and supported pull-request uploads retain their existing behavior. The update applies to Enterprise Cloud and Team, including Enterprise Cloud with data residency, rather than Enterprise Server.

This removes a misleading red signal during ordinary branch creation. A developer should not have to debug the application because a reporting step lacks review context. Clear status semantics matter: a skipped upload means the report was not sent, while a successful test means the test ran and passed. The new behavior makes that distinction easier to see if teams read the notice.

Source: GitHub official changelog

Analysis: A green job can contain missing evidence

CI dashboards compress many different outcomes into a single color. That is useful for quick triage but can hide the difference between passing work and work that did not run. Coverage gates should therefore use evidence from the intended event, not assume every green branch build contains a current coverage report. A new branch’s skipped upload is expected; a release candidate missing required coverage may need a different response.

Event configuration determines when reporting resumes. A workflow that runs only on push will not automatically upload merely because a pull request has been opened. The next push can trigger the upload, or the repository can add an appropriate pull-request event. Teams should choose deliberately rather than rely on a developer remembering to make an empty commit. The aim is a complete review record with no unnecessary build churn.

Check the review path as well as the first push

Exercise a repository’s workflow in the same sequence contributors use: create a branch, push it, open a pull request and update it. Confirm the early skip is visible and the later report attaches to the right review. Check fork and permission behavior separately where the project accepts external contributions. Reporting actions should not receive broader write access simply to make every event behave identically.

Document the expected first-push behavior in contributor instructions so a notice does not become another support question. If an organization maintains reusable workflows, update their event choices and make sure project-specific coverage requirements remain enforced. This is a small platform change with a useful lesson for build systems: expected absence should be represented honestly instead of masquerading as failure. At the same time, removing noise must not remove the evidence reviewers need before approving the final change.