[Bug]: Coverage report fails silently when PR branch is behind develop
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 88/100
Hướng nghiên cứu
Bắt đầu với .github/workflows/run_tests_coverage_pr.yml, đặc biệt là bước “Get list of changed directories”, và so sánh nó với .github/workflows/lint_changed_files.yml và .github/workflows/run_affected_tests.yml. Tái hiện workflow với một nhánh pull request đứng sau develop, sau đó xác minh rằng các thư mục đã thay đổi được phát hiện và comment coverage chứa một bảng thay vì thông báo fallback.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Description
In .github/workflows/run_tests_coverage_pr.yml, the workflow fails to detect changed packages whenever a pull request branch is behind develop. As a result, the PR coverage report comments:
Coverage Report
No coverage information available.
even though the tests run, succeed, and all other CI checks are green.
What Happens:
- Shallow Fetch of Base Branch: In
.github/workflows/run_tests_coverage_pr.yml(lines 124–127), the stepGet list of changed directoriesexecutes a shallow fetch (--depth=1). - Divergent History with No Merge Base: Because
--depth=1only fetches the single latest commit ondevelop, ifdevelophas moved forward since the feature branch was created, git cannot find a common ancestor withHEAD. - Silent Failure via
continue-on-error: Because there is no merge base in the shallow history,git diff origin/${{ github.base_ref }}...HEADfails. Because the step specifiescontinue-on-error: true, the error does not fail the job. Instead,filesanddirectoriesevaluate to an empty string"". - Coverage Script Exits Early: The downstream script
.github/workflows/scripts/run_tests_coverage/runreceives an empty directory list and exits with code0. - Bot Posts Default Fallback: Because the
$TABLEis empty, thestdlib-botpublishes the fallback "No coverage information available." comment instead of the coverage table.
Comparison with Other Workflows:
Other workflows in the repository (such as .github/workflows/lint_changed_files.yml and .github/workflows/run_affected_tests.yml) avoid this issue by computing the common ancestor commit using git merge-base. Because actions/checkout already fetches history (fetch-depth: 1000), the git merge-base calculation works reliably even if the branch is behind develop.
Proposed Fix:
Update the Get list of changed directories step in .github/workflows/run_tests_coverage_pr.yml to use git merge-base, matching the standard used in the linting workflow:
- git fetch origin ${{ github.base_ref }} --depth=1
- files=$(git diff --diff-filter=AM --name-only origin/${{ github.base_ref }}...HEAD)
+ ancestor_commit=$(git merge-base ${{ github.event.pull_request.base.sha }} ${{ github.event.pull_request.head.sha }})
+ files=$(git diff --diff-filter=AM --name-only $ancestor_commit ${{ github.event.pull_request.head.sha }})
directories=$(for file in $files; do dirname $file; done | sort -u | tr '\n' ' ' | sed 's/ $//')
echo "directories=${directories}" >> $GITHUB_OUTPUT
Related Issues
None.
Questions
If the proposed fix looks good, I am happy to open a PR to update the workflow file!
Demo
This bug can be observed in PR #15633.
- On the initial commit, the feature branch was behind
develop, and the coverage action silently failed with the fallback message. - Once
developwas merged into the PR branch (syncing the history), the coverage table generated successfully, confirming that the missing merge-base was the root cause.
Reproduction
- Open a Pull Request where the feature branch is behind
develop. - Wait for the
run_tests_coverage_pr.ymlGitHub Actions workflow to execute. - Observe the
Get list of changed directoriesstep silently failing to find changed files. - Observe the
stdlib-botcommenting the fallback text: "No coverage information available."
Expected Results
The workflow should correctly identify the changed directories using the merge base (identical to how .github/workflows/lint_changed_files.yml operates) and generate a valid coverage table for the PR.
Actual Results
The workflow silently fails to calculate the git diff due to the shallow fetch, resulting in the bot commenting a useless fallback message on the PR.
Version
develop (Latest)
Environments
N/A
Browser Version
No response
Node.js / npm Version
No response
Platform
Ubuntu (GitHub Actions Runners)
Checklist
- Read and understood the Code of Conduct.
- Searched for existing issues and pull requests.
- Ngôn ngữ chính
- JavaScript
- Star
- 6k
- Fork
- 1.3k
- Merge trung bình
- 1 ngày 10 giờ
- Pull request đã merge (30 ngày)
- 575
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
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 stdlib-js/stdlib
-
`@stdlib/string/base/percent-encode` produces malformed encoding and silently drops charactersĐang mởBug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
stdlib-js/stdlib#15595 · 6 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: kumaraswamy/kurtosis returns non-excess kurtosis (missing −3)Có thể đã có người làm @Planeshifter đã nhận 2 ngày trước. Đang mởBug Statistics
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
stdlib-js/stdlib#15461 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: rayleigh/mgf returns wrong values due to misplaced parenthesisCó thể đã có người làm @anandkaranubc đã nhận 4 ngày trước. Đang mởBug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
stdlib-js/stdlib#15456 · 6 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
stdlib-js/stdlib#15193 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Fix JavaScript lint errorsĐang mởGood First Issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
stdlib-js/stdlib#14759 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của stdlib-js/stdlib
Issue tương tự
-
refactor
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 5 ngày
-
translation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
ciderapp/translations#87 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
Maintainer thường phản hồi trong vòng 1 ngày
-
component: split-view platform: windows
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
zen-browser/desktop#15616 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày