注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。
はじめに
このガイドは、.NETパッケージのビルド、テスト、公開の方法を紹介します。
GitHub ホステッド ランナーにはプリインストールされたソフトウェアのあるツール キャッシュがあり、.NET Core SDK が含まれています。 最新のソフトウェアの完全な一覧と、.NET Core SDK のプレインストールされたバージョンについては、GitHub ホステッド ランナーにインストールされているソフトウェアに関するページを参照してください。
前提条件
YAMLの構文と、GitHub ActionsでのYAMLの使われ方に馴染んでいる必要があります。 詳しくは、「GitHub Actions のワークフロー構文」を参照してください。
.NET Core SDKの基本的な理解をしておくことをおすすめします。 詳しくは、「.NET の概要」をご覧ください。
.NET ワークフロー テンプレートの使用
すぐに開始するには、リポジトリの .github/workflows
ディレクトリにワークフロー テンプレートを追加します。
GitHub では、ほとんどの .NET プロジェクトで動作する .NET ワークフロー テンプレートが提供されています。 このガイドの以降のセクションでは、このワークフロー テンプレートをカスタマイズする方法の例を示します。
-
GitHub で、リポジトリのメイン ページに移動します。
-
リポジトリ名の下にある [アクション] をクリックします。
-
ワークフローが既にリポジトリ内にある場合は、 [新しいワークフロー] をクリックします。
-
[ワークフローの選択] ページには、推奨されるワークフロー テンプレートの選択が表示されます。 「dotnet」を検索します。
-
".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
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
-
必要に応じてワークフローを編集します。 たとえば、.NET のバージョンを変更します。
-
[変更をコミットする] をクリックします。
.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
注: 依存関係の数によっては、依存関係キャッシュを使う方が速い場合があります。 多くの大きな依存関係を持つプロジェクトでは、ダウンロードに必要な時間を節約できるので、パフォーマンスの向上が見られるでしょう。 依存関係が少ないプロジェクトでは、大きなパフォーマンスの向上は見られないかもしれず、NuGetがキャッシュされた依存関係をインストールする方法のために、パフォーマンスがやや低下さえするかもしれません。 パフォーマンスはプロジェクトによって異なります。
コードのビルドとテスト
ローカルで使うのと同じコマンドを、コードのビルドとテストに使えます。 この例では、ジョブで 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