.NETでのビルドとテスト

はじめに

このガイドは、.NETパッケージのビルド、テスト、公開の方法を紹介します。

GitHub ホステッド ランナーにはプリインストールされたソフトウェアのあるツール キャッシュがあり、.NET Core SDK が含まれています。 最新のソフトウェアの完全な一覧と、.NET Core SDK のプレインストールされたバージョンについては、GitHub ホステッド ランナーにインストールされているソフトウェアに関するページを参照してください。

前提条件

YAMLの構文と、GitHub ActionsでのYAMLの使われ方に馴染んでいる必要があります。 詳しくは、「ギットハブ　アクション　のワークフロー構文」を参照してください。

.NET Core SDKの基本的な理解をしておくことをおすすめします。 詳しくは、「.NET の概要」をご覧ください。

.NET スターター ワークフローの使用

すぐに開始するには、リポジトリの .github/workflows ディレクトリにスターター ワークフローを追加します。

GitHub では、ほとんどの .NET プロジェクトで使える .NET スターター ワークフローが提供されています。 このガイドの以降のセクションでは、このスターター ワークフローをカスタマイズする方法の例を示します。

1. お使いの GitHub Enterprise Server インスタンス で、リポジトリのメイン ページへ移動します。

2. リポジトリ名の下にある [アクション] をクリックします。

   

3. ワークフローが既にリポジトリ内にある場合は、 [新しいワークフロー] をクリックします。

4. [ワークフローの選択] ページには、推奨されるスターター ワークフローの選択が表示されます。 「dotnet」を検索します。

5. ".NET" ワークフローで、[構成] をクリックします。

   「.NET」スターター ワークフローが見つからない場合は、次のワークフロー コードをリポジトリの .github/workflows ディレクトリで dotnet.yml を呼び出した新しいファイルにコピーします。

   YAML

   name: .NET
   
   on:
     push:
       branches: [ "main" ]
     pull_request:
       branches: [ "main" ]
   
   jobs:
     build:
       runs-on: ubuntu-latest
   
       steps:
       - uses: actions/checkout@v4
       - name: Setup .NET
         uses: actions/setup-dotnet@v3
         with:
           dotnet-version: 6.0.x
       - name: Restore dependencies
         run: dotnet restore
       - name: Build
         run: dotnet build --no-restore
       - name: Test
         run: dotnet test --no-build --verbosity normal
   

6. 必要に応じてワークフローを編集します。 たとえば、.NET のバージョンを変更します。

7. [変更をコミットする] をクリックします。

.NETのバージョンの指定

GitHub ホステッド ランナーにプレインストールされたバージョンの .NET Core SDK を使うには、setup-dotnet アクションを使います。 このアクションは、各ランナーのツール キャッシュから特定のバージョンの .NET を見つけて、必要なバイナリを PATH に追加します。 これらの変更は、ジョブの残りの部分で保持されます。

setup-dotnet アクションを使用すると、異なるランナーおよび .NET の異なるバージョンの間で一貫した動作が保証されるため、GitHub Actions で NET を使用する場合の推奨される方法です。 セルフホステッド ランナーを使用している場合は、.NET をインストールし、それを PATH に追加する必要があります。 詳細については、setup-dotnet アクションを参照してください。

複数の.NETバージョンの利用

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@v4
      - name: Setup dotnet ${{ matrix.dotnet-version }}
        uses: actions/setup-dotnet@v3
        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 の最新のマイナー リリースを使用しています。

    - name: Setup .NET 6.x
      uses: actions/setup-dotnet@v3
      with:
        # Semantic version range syntax or exact version of a dotnet version
        dotnet-version: '6.x'

依存関係のインストール

GitHubホストランナーには、NuGetパッケージマネージャーがインストールされています。 コードをビルドしてテストする前に、dotnetCLIを使って依存関係をNuGetパッケージレジストリからインストールしておくことができます。 たとえば、次の YAML は Newtonsoft パッケージをインストールします。

steps:
- uses: actions/checkout@v4
- name: Setup dotnet
  uses: actions/setup-dotnet@v3
  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 へのパスを指定するために使用できます。

詳しくは、「依存関係をキャッシュしてワークフローのスピードを上げる」を参照してください。

steps:
- uses: actions/checkout@v4
- name: Setup dotnet
  uses: actions/setup-dotnet@v3
  with:
    dotnet-version: '6.x'
    cache: true
- name: Install dependencies
  run: dotnet add package Newtonsoft.Json --version 12.0.1

コードのビルドとテスト

ローカルで使うのと同じコマンドを、コードのビルドとテストに使えます。 この例では、ジョブで dotnet build と dotnet test を使用する方法を示します。

steps:
- uses: actions/checkout@v4
- name: Setup dotnet
  uses: actions/setup-dotnet@v3
  with:
    dotnet-version: '6.0.x'
- name: Install dependencies
  run: dotnet restore
- name: Build
  run: dotnet build
- name: Test with the dotnet CLI
  run: dotnet test

成果物としてのワークフローのデータのパッケージ化

ワークフローが完了すると、結果の成果物を分析のためにアップロードできます。 たとえば、ログファイル、コアダンプ、テスト結果、スクリーンショットを保存する必要があるかもしれません。 次の例では、upload-artifact アクションを使ってテスト結果をアップロードする方法を示します。

詳しくは、「ワークフロー データを成果物として保存する」を参照してください。

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@v4
        - name: Setup dotnet
          uses: actions/setup-dotnet@v3
          with:
            dotnet-version: ${{ matrix.dotnet-version }}
        - name: Install dependencies
          run: dotnet restore
        - name: Test with dotnet
          run: dotnet test --logger trx --results-directory "TestResults-${{ matrix.dotnet-version }}"
        - name: Upload dotnet test results
          uses: actions/upload-artifact@v3
          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 に公開します。

name: Upload dotnet package

on:
  release:
    types: [created]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '6.0.x' # SDK Version to use.
          source-url: https://nuget.pkg.github.com/<owner>/index.json
        env:
          NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}
      - run: dotnet build --configuration Release <my project>
      - name: Create the package
        run: dotnet pack --configuration Release <my project>
      - name: Publish the package to GPR
        run: dotnet nuget push <my project>/bin/Release/*.nupkg