Skip to main content

このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となります: 2024-03-07. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

.NETでのビルドとテスト

.NETプロジェクトのビルドとテストのための継続的インテグレーション(CI)ワークフローを作成できます。

注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

はじめに

このガイドは、.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. リポジトリ名の下にある [アクション] をクリックします。

    "github/docs" リポジトリのタブのスクリーンショット。 [アクション] タブがオレンジ色の枠線で強調表示されています。

  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

依存関係のキャッシング

一意のキーを使って NuGet の依存関係をキャッシュすることができ、これにより将来のワークフローで cache アクションによってその依存関係を復元できます。 たとえば、次の YAML は Newtonsoft パッケージをインストールします。

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

steps:
- uses: actions/checkout@v4
- name: Setup dotnet
  uses: actions/setup-dotnet@v3
  with:
    dotnet-version: '6.0.x'
- uses: actions/cache@v3
  with:
    path: ~/.nuget/packages
    # Look to see if there is a cache hit for the corresponding requirements file
    key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}
    restore-keys: |
      ${{ runner.os }}-nuget
- name: Install dependencies
  run: dotnet add package Newtonsoft.Json --version 12.0.1

注: 依存関係の数によっては、依存関係キャッシュを使う方が速い場合があります。 多くの大きな依存関係を持つプロジェクトでは、ダウンロードに必要な時間を節約できるので、パフォーマンスの向上が見られるでしょう。 依存関係が少ないプロジェクトでは、大きなパフォーマンスの向上は見られないかもしれず、NuGetがキャッシュされた依存関係をインストールする方法のために、パフォーマンスがやや低下さえするかもしれません。 パフォーマンスはプロジェクトによって異なります。

コードのビルドとテスト

ローカルで使うのと同じコマンドを、コードのビルドとテストに使えます。 この例では、ジョブで dotnet builddotnet 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