Coverage uploads silently dropped on busy default branches due to "not the latest commit" rejection
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
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
- Have a repository with frequent merges to
main(e.g. multiple per hour) - Configure the action on
pushtomain - Observe that coverage uploads succeed only when no other commit lands on
mainduring 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:
-
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).
-
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
pushevent'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
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của actions/upload-code-coverage
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
actions/upload-code-coverage#26 · 1 bình luận ·
-
Enable immutable releasesĐang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 20/100
-
Please add a LICENSE fileCó thể đã có người làm @joshhale đã nhận 3 ngày trước. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 45/100
actions/upload-code-coverage#20 · 2 bình luận · 3 reaction ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 58/100
actions/upload-code-coverage#16 · 3 bình luận · 5 reaction ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
actions/upload-code-coverage#12 · 1 bình luận · 3 reaction ·
Tất cả issue của actions/upload-code-coverage
Issue tương tự
-
Add `django-upgrade` to the CIĐang mởdependencies feature github_actions good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
wemake-services/wemake-django-template#3149 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[request] vsg/1.1.16Đang mởupstream update
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
conan-io/conan-center-index#31142 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area:core bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
request-theme
Độ khó 2/5 Dưới một giờ Mức phù hợp với người mới 70/100
LizardByte/ThemerrDB#8877 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area/install-update comp/gateway P0 sweeper:risk-compatibility type/bug
Độ khó 2/5 Dưới một giờ Mức phù hợp với người mới 72/100
NousResearch/hermes-agent#135997 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày