Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Publish merged code coverage reports from GitHub Actions

オープン
  • 何か問題がありますか？
#613 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 7 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
44/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
csharp, github-actions
領域
ci-cd, devops, testing-qa

調査の方向性

Start with .github/workflows/tests.yml and trace the existing .NET 10 core and provider test jobs, their Microsoft.Testing.Platform configuration, and test result publishing. Design the coverage collection and merge flow around those jobs, keeping .NET 8 and .NET 9 runs out of the report; document tool versions, artifact locations, retention, local reproduction, and linked source copies. Done means PR and dev runs publish a merged HTML report and Markdown summary, preserve available coverage when a suite fails, and visibly diagnose missing coverage without adding a threshold.

索引モデルが issue の本文から書いたものです。

説明

Is your feature request related to a problem? Please describe.

Coverage reports currently require a local collection run. The existing GitHub Actions test jobs publish test results, but do not provide a merged coverage report that contributors can use to identify untested behavior or review changes.

This makes it harder to discover meaningful gaps in behavioral tests and keep coverage information current as the code changes.

Describe the solution you'd like

Add coverage collection and reporting to Eventuous's existing reusable test workflow, .github/workflows/tests.yml, for pull requests and pushes to dev.

  • Collect coverage from the .NET 10 core and provider test jobs, preserving the current split between jobs and the existing .NET 8 and .NET 9 correctness tests.
  • Use coverage collection tooling compatible with this repository's Microsoft.Testing.Platform runner.
  • Upload uniquely named coverage artifacts from each job and merge them in a reporting job.
  • Generate a browsable HTML report and a Markdown summary containing line and branch coverage, including an assembly breakdown.
  • Upload the HTML report as a downloadable Actions artifact and publish the summary to GITHUB_STEP_SUMMARY.
  • Exclude test assemblies, SUT fixtures, and test helpers. Document how linked source files compiled into multiple production assemblies appear in the report, so an uncovered copy is not confused with wholly untested source.
  • Pin coverage and reporting tool versions and document a local reproduction command.

Reuse the existing test executions where practical. Do not introduce an additional whole-solution test run or combine all provider containers on one runner.

The implementation should also meet these requirements:

  • Pull request and dev workflows publish a coverage summary and downloadable HTML report.
  • The report merges the intended .NET 10 core and provider suites, without counting the .NET 8 and .NET 9 runs again.
  • Test failures continue to fail CI. Available coverage is retained when tests fail, and incomplete reports clearly identify missing suites.
  • A successful test run with unexpectedly missing coverage produces a visible failure or diagnostic rather than silently publishing a complete-looking report.
  • Report filters exclude non-production assemblies and explain linked source-file copies.
  • Fork pull requests can produce reports without repository secrets or additional write permissions.
  • Coverage artifacts are kept separate from test-result artifacts, or the test-result publisher is narrowed so it does not parse Cobertura XML as test results.
  • Tool versions, artifact locations, retention, and local reproduction steps are documented.
  • No minimum coverage percentage or coverage-based merge gate is introduced initially.

Describe alternatives you've considered

  • Continue generating reports locally. This is useful for focused investigation, but requires manual work and does not provide a consistently available report for contributors.
  • Add a separate whole-solution coverage run. This duplicates test execution and could recreate the resource and container-startup problems addressed by the current split test jobs.
  • Use an external coverage service. That could provide historical trends and PR comparisons, but downloadable Actions artifacts and a job summary would meet the initial need without an additional service.
  • Enforce coverage thresholds immediately. Establish a reliable baseline first, then consider thresholds or changed-line coverage in a separate issue.

Additional context

Validate a normal workflow run and a run with a failing test or missing suite artifact. Confirm that the summary matches the merged report and that existing test-result publishing still works.

Coverage should help locate missing behavioral tests and investigate regressions. A higher percentage alone is not a reason to add a test. Consider thresholds or changed-line coverage separately once the baseline is reliable.

Related coverage work:

  • #605: HTTP command result mapping
  • #606: Subscription partitioning
  • #607: SQLite projections
  • #608: Event-store dependency injection registrations
  • #609: Tiered event store
主要言語
C#
スター
512
フォーク
99
平均マージ
5日 6時間
マージ済み PR（30日）
5

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Eventuous/eventuous のほかの issue

Eventuous/eventuous の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。