# .NETでのビルドとテスト .NET プロジェクトのビルドとテストのための継続的インテグレーション (CI) ワークフローを作成する方法について説明します。 ## はじめに このガイドは、.NETパッケージのビルド、テスト、公開の方法を紹介します。 GitHub ホステッド ランナーにはプリインストールされたソフトウェアのあるツール キャッシュがあり、.NET Core SDK が含まれています。 最新のソフトウェアの完全な一覧と、.NET Core SDK のプレインストールされたバージョンについては、[GitHub ホステッド ランナーにインストールされているソフトウェア](/ja/enterprise-cloud@latest/actions/using-github-hosted-runners/about-github-hosted-runners)に関するページを参照してください。 ## 前提条件 YAMLの構文と、GitHub ActionsでのYAMLの使われ方に馴染んでいる必要があります。 詳しくは、「[GitHub Actions　のワークフロー構文](/ja/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions)」をご覧ください。 .NET Core SDKの基本的な理解をしておくことをおすすめします。 詳しくは、「[.NET の概要](https://dotnet.microsoft.com/learn)」をご覧ください。 ## .NET ワークフロー テンプレートの使用 すぐに開始するには、リポジトリの `.github/workflows` ディレクトリにワークフロー テンプレートを追加します。 GitHub では、ほとんどの .NET プロジェクトで動作する .NET ワークフロー テンプレートが提供されています。 このガイドの以降のセクションでは、このワークフロー テンプレートをカスタマイズする方法の例を示します。 1. GitHub で、リポジトリのメイン ページに移動します。 2. リポジトリ名の下にある **\[ Actions]** をクリックします。 !["github/docs" リポジトリのタブのスクリーンショット。 \[アクション\] タブがオレンジ色の枠線で強調表示されています。](/assets/images/help/repository/actions-tab-global-nav-update.png) 3. ワークフローが既にリポジトリ内にある場合は、 **\[新しいワークフロー]** をクリックします。 4. \[ワークフローの選択] ページには、推奨されるワークフロー テンプレートの選択が表示されます。 「dotnet」を検索します。 5. ".NET" ワークフローで、\[**構成**] をクリックします。 6. 必要に応じてワークフローを編集します。 たとえば、.NET のバージョンを変更します。 7. ``` **[変更をコミットする]** をクリックします。 ``` `dotnet.yml` ワークフロー ファイルがリポジトリの `.github/workflows` ディレクトリに追加されます。 ## .NETのバージョンの指定 GitHub ホステッド ランナーにプレインストールされたバージョンの .NET Core SDK を使うには、`setup-dotnet` アクションを使います。 このアクションは、各ランナーのツール キャッシュから特定のバージョンの .NET を見つけて、必要なバイナリを `PATH` に追加します。 これらの変更は、ジョブの残り時間にわたって持続します。 ``` `setup-dotnet` アクションを使用すると、異なるランナーおよび .NET の異なるバージョンの間で一貫した動作が保証されるため、GitHub Actions で NET を使用する場合の推奨される方法です。 セルフホステッド ランナーを使用している場合は、.NET をインストールし、それを `PATH` に追加する必要があります。 詳細については、[`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk) アクションを参照してください。 ``` ### 複数の.NETバージョンの利用 ```yaml name: dotnet package on: [push] jobs: build: runs-on: ubuntu-latest strategy: matrix: dotnet-version: [ '3.1.x', '6.0.x' ] steps: - uses: actions/checkout@v6 - name: Setup dotnet ${{ matrix.dotnet-version }} uses: actions/setup-dotnet@v4 with: dotnet-version: ${{ matrix.dotnet-version }} # You can test your matrix by printing the current dotnet version - name: Display dotnet version run: dotnet --version ``` ### 特定のバージョンの.NETの利用 ``` `6.0.22` のような特定のバージョンの .NET を使うようにジョブを構成できます。 あるいは、最新のマイナーリリースを取得するためにセマンティックバージョン構文を使うこともできます。 この例では、.NET 6 の最新のマイナー リリースを使用しています。 ``` ```yaml - name: Setup .NET 6.x uses: actions/setup-dotnet@v4 with: # Semantic version range syntax or exact version of a dotnet version dotnet-version: '6.x' ``` ## 依存関係のインストール GitHubホストランナーには、NuGetパッケージマネージャーがインストールされています。 コードをビルドしてテストする前に、dotnetCLIを使って依存関係をNuGetパッケージレジストリからインストールしておくことができます。 たとえば、次の YAML は `Newtonsoft` パッケージをインストールします。 ```yaml steps: - uses: actions/checkout@v6 - name: Setup dotnet uses: actions/setup-dotnet@v4 with: dotnet-version: '6.0.x' - name: Install dependencies run: dotnet add package Newtonsoft.Json --version 12.0.1 ``` ### 依存関係のキャッシング オプション `cache` の入力を使用して、将来のワークフローの NuGet 依存関係をキャッシュできます。 たとえば、次の YAML は NuGet `global-packages` フォルダーをキャッシュし、`Newtonsoft` パッケージをインストールします。 2 番目のオプション入力 `cache-dependency-path` は、依存ファイル `packages.lock.json` へのパスを指定するために使用できます。 詳しくは、「[依存関係キャッシュのリファレンス](/ja/enterprise-cloud@latest/actions/using-workflows/caching-dependencies-to-speed-up-workflows)」をご覧ください。 ```yaml steps: - uses: actions/checkout@v6 - name: Setup dotnet uses: actions/setup-dotnet@v4 with: dotnet-version: '6.x' cache: true - name: Install dependencies run: dotnet add package Newtonsoft.Json --version 12.0.1 ``` > \[!NOTE] > 依存関係の数によっては、依存関係キャッシュを使う方が速い場合があります。 多くの大きな依存関係を持つプロジェクトでは、ダウンロードに必要な時間を節約できるので、パフォーマンスの向上が見られるでしょう。 依存関係が少ないプロジェクトでは、大きなパフォーマンスの向上は見られないかもしれず、NuGetがキャッシュされた依存関係をインストールする方法のために、パフォーマンスがやや低下さえするかもしれません。 パフォーマンスはプロジェクトによって異なります。 ## コードのビルドとテスト ローカルで使うのと同じコマンドを、コードのビルドとテストに使えます。 この例では、ジョブで `dotnet build` と `dotnet test` を使用する方法を示します。 ```yaml steps: - uses: actions/checkout@v6 - name: Setup dotnet uses: actions/setup-dotnet@v4 with: dotnet-version: '6.0.x' - name: Install dependencies run: dotnet restore - name: Build run: dotnet build --no-restore - name: Test with the dotnet CLI run: dotnet test --no-build ``` ## 成果物としてのワークフローのデータのパッケージ化 ワークフローが完了すると、結果の成果物を分析のためにアップロードできます。 たとえば、ログファイル、コアダンプ、テスト結果、スクリーンショットを保存する必要があるかもしれません。 次の例では、`upload-artifact` アクションを使ってテスト結果をアップロードする方法を示します。 詳しくは、「[ワークフロー成果物を使ったデータの格納と共有](/ja/enterprise-cloud@latest/actions/using-workflows/storing-workflow-data-as-artifacts)」をご覧ください。 ```yaml name: dotnet package on: [push] jobs: build: runs-on: ubuntu-latest strategy: matrix: dotnet-version: [ '3.1.x', '6.0.x' ] steps: - uses: actions/checkout@v6 - name: Setup dotnet uses: actions/setup-dotnet@v4 with: dotnet-version: ${{ matrix.dotnet-version }} - name: Install dependencies run: dotnet restore - name: Test with dotnet run: dotnet test --no-restore --logger trx --results-directory "TestResults-${{ matrix.dotnet-version }}" - name: Upload dotnet test results uses: actions/upload-artifact@v4 with: name: dotnet-results-${{ matrix.dotnet-version }} path: TestResults-${{ matrix.dotnet-version }} # Use always() to always run this step to publish test results when there are test failures if: ${{ always() }} ``` ## パッケージレジストリへの公開 CI テストに合格したら .NET パッケージをパッケージ レジストリに公開するように、ワークフローを構成できます。 バイナリを公開するのに必要なトークンや認証情報を保存するために、リポジトリシークレットを使うことができます。 次の例では、`dotnet core cli` を使ってパッケージを作成し、GitHub Packages に公開します。 ```yaml name: Upload dotnet package on: release: types: [created] jobs: deploy: runs-on: ubuntu-latest permissions: packages: write contents: read steps: - uses: actions/checkout@v6 - uses: actions/setup-dotnet@v4 with: dotnet-version: '6.0.x' # SDK Version to use. source-url: https://nuget.pkg.github.com//index.json env: NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}} - run: dotnet build --configuration Release - name: Create the package run: dotnet pack --configuration Release - name: Publish the package to GPR run: dotnet nuget push /bin/Release/*.nupkg ```