Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Coverage uploads silently dropped on busy default branches due to "not the latest commit" rejection

Đang mở
#10 1 bình luận 5 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
45/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
github-actions, python
Lĩnh vực
api, ci-cd

Hướng nghiên cứu

Bắt đầu với action.yml để xác nhận các giá trị commit và ref của push-event, sau đó điều tra việc xác thực API phía máy chủ từ chối các commit không ở tip. Công việc được xem là hoàn tất khi coverage cho một commit có thể truy cập trên ref được chấp nhận và lưu trữ mà không yêu cầu commit đó vẫn là tip mới nhất của branch.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Problem

On repositories with frequent merges to the default branch, coverage uploads for push events are almost always rejected with:

Warning: Coverage upload returned HTTP 200 (report not stored): Coverage report for <sha> cannot be uploaded for main because it is not the latest commit on the branch

This happens because CI takes time (install deps, build, test, upload) — often several minutes. In an active repository, another PR is typically merged to main before the workflow finishes. At that point the commit that triggered the workflow is no longer the branch tip, and the API refuses to store the report.

The result is that busy repositories can never get coverage data on their default branch, which is the primary use case for tracking coverage trends over time.

Reproduction

  1. Have a repository with frequent merges to main (e.g. multiple per hour)
  2. Configure the action on push to main
  3. Observe that coverage uploads succeed only when no other commit lands on main during the CI run — which on active repos is rare

Suggested improvement

Looking at action.yml, for push events the action currently sends:

COMMIT_OID="${{ github.sha }}"
REF="${{ github.ref }}"

The server-side API then validates that COMMIT_OID is the current tip of REF and rejects otherwise. This design makes coverage upload inherently racy for any branch with concurrent activity.

Proposed solution

Coverage data is valid for the commit it was generated from, regardless of whether newer commits exist on the branch. The API should accept and store coverage for any commit reachable on the ref, not only the tip. The "latest" constraint could be relaxed to:

  1. Accept coverage for any commit on the branch — Store it keyed by commit SHA. The UI/API can still display the most recent report when showing "current branch coverage," but historical reports for older commits remain queryable and useful (e.g. for trend lines, PR comparisons against the base commit at the time the PR was opened).

  2. If the API must keep "latest only" semantics for display purposes, at minimum allow uploads for commits that were the tip when the workflow was triggered (i.e. trust the push event's SHA as valid), even if the tip has since advanced. The workflow event itself proves the commit was on the branch.

Alternative client-side mitigations (less ideal)
  • Retry with updated SHA: The action could fetch the current branch tip and re-upload, but the coverage data wouldn't match that commit's code — this is semantically wrong.
  • Upload earlier in the workflow: Not practical since coverage requires tests to complete first.

Impact

This affects any team using the action on a default branch with more than a handful of merges per day. As adoption grows, this will become more prevalent. Currently there is no workaround — the upload either wins the race or the data is lost.

This is also tricky for us, because only run certain tests if the relevant code has changed. Future commits may not even trigger the test run.

Thank you for building this action. The integration is clean and the DX is excellent. This is the one rough edge we've hit in practice.

Ngôn ngữ chính
Python
Star
102
Fork
21
Merge trung bình
1 ngày 11 giờ
Pull request đã merge (30 ngày)
8

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của actions/upload-code-coverage

Tất cả issue của actions/upload-code-coverage

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.