feat: merge lcov reports from sharded test runs
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ó
- 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
- 42/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- dart
- Lĩnh vực
- cli, testing-qa
Hướng nghiên cứu
Start in lib/src/cli/test_cli_runner.dart, reading CoverageMetrics.fromLcovRecords and MinCoverageNotMet to understand the existing coverage parsing and reporting flow. Review the sharding behavior from #1707 and the requirements for combining records, path handling, configuration, and output. Done means a command merges multiple lcov files, applies the existing coverage checks and very_good.yaml fallback, writes the result, and includes the requested documentation and CI updates.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Description
#1707 adds --shard-index and --total-shards to very_good test and very_good dart test, so a suite can be split across CI runners with a strategy.matrix. Sharding and --min-coverage don't mix well yet. Each shard runs only part of the suite, so its coverage/lcov.info reflects only the code that slice touches. With --collect-coverage-from all, _enhanceLcovWithUntestedFiles also adds every file the shard never loaded at 0%. A shard's percentage is always well below the real number, and a threshold check on it fails healthy builds.
#1707 handles this by rejecting an explicit --min-coverage when sharding. The error tells users to collect coverage per shard with --coverage, merge the lcov reports, and enforce the threshold once in a separate job. The CLI has no way to do those last two steps today, so teams have to reach for lcov or a custom script. A threshold set in very_good.yaml is also ignored silently when sharding, so teams that rely on it lose enforcement without being told.
This issue proposes that the CLI merge the shard reports and run the coverage checks on the merged result.
A possible shape:
jobs:
test:
strategy:
matrix:
shard: [1, 2, 3]
steps:
- run: very_good test --coverage --shard-index ${{ matrix.shard }} --total-shards 3
- uses: actions/upload-artifact@v4
with:
name: coverage-${{ matrix.shard }}
path: coverage/lcov.info
coverage:
needs: test
steps:
- uses: actions/download-artifact@v4
- run: very_good test coverage merge coverage-*/lcov.info --min-coverage 100
The command name and placement are open for discussion. It could live under very_good test or as a new top-level command.
Things the merge has to get right:
- Union hits, don't average percentages. A line counts as covered when any shard hit it. For each source file, sum the per-line hit counts across reports and recompute totals from the merged lines.
- 0% records from
--collect-coverage-from allmust merge cleanly. A file one shard added at 0% and another shard actually covered should end up covered. - Path consistency. Reports from different runners have to agree on each file's path. If
SF:entries can be absolute and runners check out to different directories, paths need normalizing relative to the project root. - Reuse the existing checks.
--min-coverage,--exclude-coverageand--show-uncoveredshould behave exactly as they do in a normal run.CoverageMetrics.fromLcovRecordsandMinCoverageNotMetinlib/src/cli/test_cli_runner.dartalready do the parsing and reporting, so the merge only needs to feed them a combined set of records. - Fall back to
very_good.yaml. The merge step should pick up the threshold fromvery_good.yamlthe same wayvery_good testdoes, which closes the silent-skip gap for sharded runs. - Write the merged report to disk so it can still go to Codecov or be rendered with
genhtml.
#804 asked for something close to this for multi-package apps run with -r, where each package writes its own lcov file. It was closed without a merge feature. The same merge logic would serve both cases, so it's worth designing with both in mind.
Requirements
- A command merges two or more lcov files into a single report.
- Hit counts are combined per file and per line, so a line covered in any input counts as covered.
-
--min-coverage,--exclude-coverageand--show-uncoveredwork on the merged report and match the output of a normalvery_good testrun. - The minimum coverage threshold falls back to
very_good.yamlwhen the flag is not passed. - The merged report is written to a configurable output path.
- The
--min-coverageusage error added in #1707 points to the new command. - Docs describe the sharded CI workflow from start to finish.
- All CI/CD checks are passing.
- There is no drop in the test coverage percentage.
Additional Context
- #1707: sharding PR that rejects
--min-coverageand suggests merging reports - #1538: original sharding request
- #804: earlier request for a single coverage report across multi-package runs
- Ngôn ngữ chính
- Dart
- Star
- 2.4k
- Fork
- 244
- Merge trung bình
- 21 giờ 32 phút
- Pull request đã merge (30 ngày)
- 33
Chuẩn bị môi trường
- 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 VeryGoodOpenSource/very_good_cli
-
feature
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 38/100
VeryGoodOpenSource/very_good_cli#1695 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
feat(mcp): stream progress notifications for long-running toolsCó thể làm lại được @vgvbot đã nhận 51 ngày trước và không có pull request nào đang mở. Đang mởfeature
VeryGoodOpenSource/very_good_cli#1616 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
feature
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
VeryGoodOpenSource/very_good_cli#1363 · 4 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[CI - test_optimizer] GitHub Actions, Melos, very_good test lead sometimes to cache errorCó thể làm lại được @erickzanardo đã nhận 344 ngày trước và không có pull request nào đang mở. Đang mởbug p1
VeryGoodOpenSource/very_good_cli#947 · 13 bình luận · 15 reaction · 3 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
feature p2
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
VeryGoodOpenSource/very_good_cli#682 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của VeryGoodOpenSource/very_good_cli
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
Maintainer thường phản hồi trong vòng 3 ngày
-
analyzer package size is ~48MB on pub — test files (~20MB) could be excluded with .pubignoreĐang mởarea-dart-model
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
dart-lang/sdk#64436 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 4 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
immich-app/immich#31955 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Feature] 配置页「更新」与「添加配置」的位置Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100