ツイートはてブ LINE Pocket

dotCover

dotCover ランナーは、JetBrains dotCover を使用して .NET プロセスのカバレッジレポートを生成します。生成されたレポートは、ビルド結果ページのコードカバレッジタブに公開されます。

このランナーは、複数の先行する .NET ステップの後に配置して、個々のコードカバレッジをマージし、統合レポートを公開することもできます。

dotCover ステップ設定

このセクションでは、ランナー設定の使用方法について説明します。現在のタスクに応じてこれらの設定を組み合わせる方法の例については、以下のセクションを参照してください。

dotCover ツール - dotCover のプリインストール版またはカスタム版を選択します。
dotCover 2025.2 は、現在の TeamCity バージョンとはまだ互換性のない新しい構文を導入しています。このツールを利用する TeamCity ランナー（dotCover、.NET、NUnit）は、今後のリリースでアップデートされる予定です。
それまでは、エージェントに dotCover 2025.2 をインストールし、「dotCover バージョン」ランナー設定の＜カスタム＞オプションで選択しないでください。代わりに、クロスプラットフォーム版 2025.1.7、または TeamCity インストールにバンドルされているバージョンを使用してください。
実行可能ファイルとコマンドライン引数 — dotCover カバレッジプロファイルで必要な引数を使用してカスタムプロセスを実行できるようにするオプション設定。実行可能ファイルフィールドは、プロファイルするプロセスを生成するオブジェクトへのパスを受け入れます (たとえば、.NET CLI または dotCover ツール自体の .exe/.dll)。このステップを使用して、先行する dotCover、.NET、または NUnit ランナーによって生成されたスナップショットをマージする場合は、これらの設定を空のままにします。
カバレッジレポートの生成 — ビルド結果ページのコードカバレッジタブに生成されたコードカバレッジレポートのデータを表示するかどうかを指定します。
ビルド結果ページでレポートを公開する必要がない場合は、この設定をオフのままにしておきます。例: 生成された .html および .dcvr ファイルをビルドアーティファクトとして公開し、他の場所で使用する場合。
追加の dotCover スナップショットをレポートに含める — ランナーが最終的なカバレッジレポートを生成するために使用する .dcvr スナップショットへのパス。複数の .dcvr ファイルをリストし、実行可能ファイルの設定を空のままにすることもできます。この場合、dotCover はこれらのスナップショットをマージしたレポートを生成します。
dotCover は、前の dotCover および .NET ステップからスナップショットを自動的に収集するため、必要なすべてのスナップショットが同じ構成で作成される限り、これらのルールを定義する必要がないことに注意してください。この設定により、アーティファクトの依存関係を介してインポートされたスタンドアロン構成からのスナップショットを含めることができます。

詳細設定

集合フィルター — コードカバレッジにアセンブリを含めるには「+:assemblyName」と入力し、コードカバレッジにアセンブリを除外するには「-:assemblyName」と入力します。
属性フィルター — この属性でマークされたコードをコードカバレッジから除外するには、「-:attributeName」と入力します。
追加引数 — dotCover cover コマンドの追加のコマンドライン引数のリスト。

サンプル: 統合レポートの生成

dotCover ランナーは、必要なプロジェクトをテストし、コードカバレッジレポートを生成するワンストップショップとして使用できます。次の Kotlin DSL サンプルは、このセットアップを示しています。

// Launching .NET to test a project and generate a report
object MyConfig : BuildType({
    steps {
        dotCover {
            name = "dotCover step with .Net test"
            id = "dotcover"
            toolPath = "%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%"
            executable = "%DotNetCLI_Path%"
            commandLineArguments = """test %teamcity.build.checkoutDir%\ProjectA\proj_A.csproj"""
        }
    }
})

// Launching .NET to test a project and generate a report
object MyConfig : BuildType({
    steps {
        dotCover {
            id = "dotcover"
            toolPath = "%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%"
            executable = "%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%/dotCover.dll"
            commandLineArguments = "dotnet --targetWorkingDir=%teamcity.build.checkoutDir% -- test ./ProjectA/proj_A.csproj"
        }
    }
})

ただし、この単純なシナリオでは、最終結果は、設定で dotNet カバレッジを有効にして .NET ステップを実行した場合と似ています。dotCover ランナーの真の強みは、さまざまなソースからスナップショットを収集し、結合されたコードカバレッジレポートを生成する機能にあります。以下のサンプルは、これらのスナップショットの正確なソースに応じて dotCover ランナーを設定する方法を示しています。

単一のビルド構成から

以下のサンプル構成には、異なるプロジェクトをテストする複数の .NET ステップが含まれています。これらの各ステップでは、コードカバレッジで「JetBrains dotCover」が選択されています。最後の dotCover ステップでは、独自のスナップショットは生成されません。代わりに、すべての .NET ランナーのスナップショットを収集して、コードカバレッジタブに公開される最終的な統合レポートを作成します。

このセットアップでは、カバレッジレポートの生成オプションを選択することのみが必要で、他のランナー設定は空のままです。

import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildSteps.dotCover

object ConsolidatedReport : BuildType({
    id("consolidatedreport")
    name = "Code coverate report merged from three .NET steps"
    

    steps {
         dotnetTest {
             id = "dotnet"
             projects = "projectA/proj_A.csproj"
             sdk = "6"
             coverage = dotcover {
                 toolPath = "%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%"
             }
         }
        dotnetTest {
            id = "dotnet_1"
            projects = "projectB/proj_B.csproj"
            sdk = "6"
            coverage = dotcover {
                toolPath = "%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%"
            }
        }
        
        // More .NET runners that test separate projects and generate dotCover snapshots
        
        dotCover {
            id = "dotcover"
            toolPath = "%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%"
        }
    }
})

ビルドチェーンから

以下のビルドチェーンには、2 つの構成が含まれています。

構成 A では、.NET ステップを実行して、コードカバレッジを使用して個々のプロジェクトをテストします。生成された .dcvr スナップショットはアーティファクトとして公開されます。

import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildSteps.dotCover

object ConfigA : BuildType({
    name = "Configuration A: Test with code coverage and publish snapshots"
    // Publish snaphots
    // Note that the path to the snapshot directory may vary depending on the runner type and/or settings
    // For example, for NUnit runner use "%teamcity.agent.work.dir%\..\temp\agentTmp\dotNetCoverageResults\*.dcvr" instead
    artifactRules = """%teamcity.agent.work.dir%\..\temp\agentTmp\*.dcvr"""
    
    steps {
        dotnetTest {
            id = "dotnet"
            projects = "projectA/proj_A.csproj"
            sdk = "6"
            coverage = dotcover {
                toolPath = "%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%"
            }
        }
        dotnetTest {
            id = "dotnet_1"
            projects = "projectB/proj_B.csproj"
            sdk = "6"
            coverage = dotcover {
                toolPath = "%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%"
            }
        }
        // ...
        // More .NET runners that test separate projects and generate dotCover snapshots 
    }
})

構成 B の最後の dotCover ステップでは、次のスナップショットを組み合わせて共同レポートを作成します。
- 構成 B の .NET ステップによって生成されたスナップショット (「プロジェクト C」のテスト)
- dotCover による「プロジェクト D」のテスト中のスナップショット
- 構成 A によって生成され、アーティファクト依存関係を介して構成 B にインポートされたスナップショット

import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildSteps.dotCover

object ConfigB : BuildType({
    name = "Configuration B: Test with code coverage, import snapshots, and publish report"

    steps {
        dotnetTest {
            id = "dotnet"
            projects = "projectC/proj_C.csproj"
            sdk = "6"
            coverage = dotcover {
                toolPath = "%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%"
            }
        }
        dotCover {
            id = "dotcover"
            toolPath = "%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%"
            executable = "%DotNetCLI_Path%"
            commandLineArguments = "test ./ProjectD"
            snapshotPaths = "%teamcity.build.workingDir%/*.dcvr"
        }
    }

    dependencies {
        artifacts(Build) {
            buildRule = lastSuccessful()
            cleanDestination = true
            artifactRules = "+:*.dcvr"
        }
    }
})

並列テストから

.NET ランナーは、並列テストビルド機能を使用して、巨大なテストスイートを個別のバッチに分割し、異なるエージェントで実行することができます。並列テストを含む構成に dotCover ステップを追加した場合、個別のバッチを実行する個別のビルドによって生成されたスナップショットはマージされません。各個別のビルドは、ビルド結果ページの概要タブに独自の結果を表示し、統合レポートを含むコードカバレッジタブは表示されません。

統合レポートが必要な場合は、ビルドチェーンからセクションに示されているものと同様のソリューションを採用できます。つまり、すべてのバッチからスナップショットを収集し、1 つのレポートに結合する依存ビルド構成を作成します。

この使用例の違いは、スナップショットをアーティファクトとして公開する前にスナップショットの名前を変更する必要があることです。それ以外の場合、各並列ビルドは同一の設定を持つため、スナップショットの名前は同一になり、より高速な並列ビルドの後に終了する各ビルドはそのアーティファクトをオーバーライドします。詳細については、次のセクションを参照してください: バッチビルドによって生成されたアーティファクトの公開

// Primary build configuration
// Performs actual tests and generates coverage snapshots
object PrimaryConfig : BuildType({
    id = AbsoluteId("ConfigA")
    name = "Build"
    // use build.parallelTests parameter to generate unique artifact names
  artifactRules = """%teamcity.agent.work.dir%\..\temp\agentTmp\*.dcvr => Snapshot_%teamcity.build.parallelTests.currentBatch%"""

    steps {
        dotnetTest {
            id = "dotnet_1"
            projects = "ProjectA/proj_A.csproj"
            sdk = "6"
            coverage = dotcover {
                toolPath = "%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%"
            }
        }
        // .NET runners that test separate projects and generate dotCover snapshots
    }

    features {
        parallelTests {
            numberOfBatches = 2
        }
    }
})

// Dependent build configuration
// Retrieves snapshots from parallel builds and produces a consolidated report
object DotCoverReportConfig : BuildType({
    id = AbsoluteId("ConfigB")
    name = "dotCover Report"

    steps {
        dotCover {
            id = "dotcover"
            toolPath = "%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%"
            snapshotPaths = "%teamcity.build.workingDir%/*/*.dcvr"
        }
    }

    dependencies {
        artifacts(DotCoverRunner_ParallelTestsWithOneCommonCoverageReport_Build) {
            buildRule = lastSuccessful()
            cleanDestination = true
            artifactRules = "+:*/*.dcvr"
        }
    }
})

2025 年 10 月 27 日

関連ページ：

ビルド結果ページ

TeamCity では、ビルドに関するすべての情報 (キューに入っているか、実行中か、完了しているかに関係なく) がビルド結果ページに蓄積されます。ビルド結果を表示するには、任意の構成を選択してビルド履歴を表示し、必要なビルド番号をクリックします。このページには、いくつかの静的タブ（概要、変更、ビルドログ、アーティファクトなど）と、特定の構成機能に応じて表示されるコンテキストタブが含まれています。例: 依存関係タブは、親構成がビルドチェーンに属するビルドに対してのみ表示されます。内部ビルド ID：...

.NET

TeamCity.NET ビルドステップを使用すると、.NET (Core) および .NET フレームワークを対象とするアプリケーションをビルド、テスト、デプロイできるほか、NuGet パッケージをダウンロードしてプッシュすることもできます。.NET ステップイン構成とパイプライン：クラシックビルド構成では、.NET は、選択したコマンドに応じて設定が変化する単一のビルドステップです。パイプラインでは、これらの各コマンドは個別のビルドステップとして使用できます。エージェント要件：.NET ス...

エージェントツールのインストール

TeamCity では、エージェントツールは、エージェントを構築するためのファイルをディストリビューションするためだけに使われるプラグインの一種です。エージェントツールは、ファイルのセットまたはバイナリディストリビューションになります。そのクラスはランタイムにロードされません。TeamCity を使用すると、サーバー上で追加のツールをインストール / 削除し、オンデマンドでエージェントを構築するために配布することができます。ビルドエージェントが多数ある環境では、構成ファイルのディストリビューショ...

アーティファクトの依存関係

このページでは、あるビルドから別のビルドにファイルを渡すことができる TeamCity アーティファクトの依存関係の構成について詳しく説明します。例: 一般的なデプロイビルド構成は、他の (本番) 構成によって生成されたファイルを公開します。アーティファクトは以下から渡すことができます: 同じビルドチェーン内のターゲット構成の前に実行される構成。ターゲット構成と同じビルドチェーンの一部ではない個別の構成。同じ構成の以前のビルド。Web UI を使用したアーティファクトの依存関係の設定：ビルド構成...

Kotlin DSL

TeamCity では、バージョン管理で設定を XML 形式で保存するだけでなく、DSL (Kotlin 言語に基づく) で設定を保存することもできます。バージョン管理に保存された DSL を使用すると、プログラムで設定を定義できます。Kotlin は静的に型指定されるため、IDE で自動補完機能を自動的に受け取ります。これにより、利用可能な API オプションの発見がはるかに簡単になります。TeamCity での Kotlin DSL の使用に関するブログ投稿シリーズと推奨リファクタリングの記...

ビルドチェーン

ビルドチェーンは、相互接続されたビルド構成とパイプラインの作成と編集のシーケンスです。チェーンは、完全に実行することも、部分的に実行することもできます。どちらの場合も、トリガーされた構成またはパイプラインによって、その上流の依存オブジェクトが最初に実行されます。例: 下のダイアグラムは、サンプルビルドチェーンを示しています。+------------+ +----------------+ +--------+ | Build core |---->| Build plugin A |--...