GitHub Actions .NET
この概要では、.NET アプリケーション開発における GitHub Actions の役割について説明します。 GitHub Actions では、ソース コード リポジトリで継続的インテグレーション (CI) と継続的デリバリー (CD) を自動化できます。 さらに GitHub Actions では、コード レビューやブランチ管理、課題のトリアージを自動化するためのフックの提供など、より高度なシナリオを公開することができます。 GitHub の .NET ソース コードを使用すると、さまざまな方法で GitHub Actions を活用できます。
GitHub のアクション
GitHub Actions は、次のようなスタンドアロン コマンドを表します。
- actions/checkout - このアクションを使って、
$GITHUB_WORKSPACE
の下のリポジトリをチェックアウトして、ワークフローからアクセスできるようにします。 - actions/setup-dotnet - このアクションを使って、アクションで使用する.NET CLI 環境を設定します。
- dotnet/versionsweeper - このアクションを使って、.NET リポジトリで .NET のサポート対象外のターゲット バージョンを見つけて一掃します。
これらのコマンドは単一のアクションに分離されていますが、"ワークフロー構成" によって強化されています。 ワークフロー構成で、ワークフローをトリガーする "イベント" を定義します。 ワークフローが実行されると、さまざまな "ジョブ" の実行が指示されます。 各ジョブは、任意の数のステップを定義します。 "ステップ" は、GitHub Actions に委任するか、またはコマンドライン スクリプトを呼び出します。
詳細については、「GitHub Actions 入門」を参照してください。 ワークフロー ファイルは、アプリケーションをビルド、テスト、発行するためのさまざまな手順を表すコンポジションと考えてください。 多くの .NET CLI コマンドが用意されており、そのほとんどが GitHub Action のコンテキストで使用できます。
カスタム GitHub Actions
Marketplace には GitHub Actions が多数用意されていますが、独自に作成することもできます。 .NET アプリケーションを実行する GitHub Actions を作成できます。 詳細については、「チュートリアル: .NET を使用して GitHub Action を作成する」を参照してください
ワークフロー ファイル
GitHub Actions は、ワークフロー ファイルを介して利用します。 ワークフロー ファイルは、リポジトリの .github/workflows ディレクトリに配置する必要があり、YAML (* .yml または * .yaml) が想定されています。 ワークフロー ファイルには、"ワークフロー構成" を定義します。 ワークフローは、1 つ以上のジョブからなる設定可能な自動化プロセスです。 詳しくは、「GitHub Actions のワークフロー構文」を参照してください。
ワークフロー ファイルの例
.NET ワークフロー ファイルの数多くの例が、チュートリアルやクイックスタートとして提供されています。 次に、ワークフロー ファイル名の好例をいくつか示します。
ワークフロー ファイル名
説明
ソース コードをコンパイル (またはビルド) します。 ソース コードがコンパイルされない場合、これは失敗します。
リポジトリ内の単体テストを実行します。 テストを実行するには、最初にソース コードをコンパイルする必要があります。これは、実際にはビルドとテストのワークフローです (build-validation.yml ワークフローよりも優先されます)。 単体テストに失敗すると、ワークフローが失敗します。
ソース コードをパッケージ化して宛先に発行します。
コードを分析して、セキュリティの脆弱性とコーディング エラーを見つけます。 検出された脆弱性によってエラーが引き起こされるおそれがあります。
暗号化されたシークレット
ワークフロー ファイルで "暗号化されたシークレット" を使用するには、secrets
コンテキスト オブジェクトからワークフロー式の構文を使用してシークレットを参照します。
${{ secrets.MY_SECRET_VALUE }} # The MY_SECRET_VALUE must exist in the repository as a secret
シークレット値がログに出力されることはありません。 代わりに、その名前とその値を表すアスタリスクが出力されます。 たとえば、各ステップがジョブ内で実行されると、使用されるすべての値がアクション ログに出力されます。 シークレット値は次のようにレンダリングされます。
MY_SECRET_VALUE: ***
重要
secrets
コンテキストにより、リポジトリ、ブランチ、アクションにスコープが設定されている GitHub 認証トークンが提供されます。 これは、ユーザーの介入なしに GitHub から提供されます。
${{ secrets.GITHUB_TOKEN }}
詳細については、「暗号化されたシークレットのワークフロー内での利用」を参照してください。
events
ワークフローは、さまざまな種類のイベントによってトリガーされます。 最も一般的な Webhook イベントに加えて、スケジュールされたイベントと手動イベントもあります。
Webhook イベントの例
次の例は、ワークフローの Webhook イベント トリガーを指定する方法を示しています。
name: code coverage
on:
push:
branches:
- main
pull_request:
branches:
- main, staging
jobs:
coverage:
runs-on: ubuntu-latest
# steps omitted for brevity
上記のワークフローでは、push
および pull_request
イベントによってワークフローの実行がトリガーされます。
スケジュールされたイベントの例
次の例は、ワークフローのスケジュールされた (cron ジョブ) イベント トリガーを指定する方法を示しています。
name: scan
on:
schedule:
- cron: '0 0 1 * *'
# additional events omitted for brevity
jobs:
build:
runs-on: ubuntu-latest
# steps omitted for brevity
上記のワークフローでは、schedule
イベントで、cron
に '0 0 1 * *'
を指定して、毎月 1 日に実行されるワークフローをトリガーします。 ワークフローをスケジュールに従って実行することは、実行に時間がかかるワークフローや、それほど頻繁に注意を払う必要のないアクションを実行する場合に最適です。
手動イベントの例
次の例は、ワークフローの手動イベント トリガーを指定する方法を示しています。
name: build
on:
workflow_dispatch:
inputs:
reason:
description: 'The reason for running the workflow'
required: true
default: 'Manual run'
# additional events omitted for brevity
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: 'Print manual run reason'
if: ${{ github.event_name == 'workflow_dispatch' }}
run: |
echo 'Reason: ${{ github.event.inputs.reason }}'
# additional steps omitted for brevity
上記のワークフローでは、workflow_dispatch
イベントは、入力として reason
を必要としています。 GitHub によってこれが認識されると、UI が動的に変更され、ユーザーは、ワークフローを手動で実行する理由を提供するように促されます。 steps
で、ユーザーから提供された理由が出力されます。
詳細については、「ワークフローをトリガーするイベント」を参照してください。
.NET CLI
.NET コマンド ライン インターフェイス (CLI) は、.NET アプリケーションを開発、ビルド、実行、発行するためのクロスプラットフォーム ツールチェーンです。 .NET CLI は、ワークフロー ファイル内の個々の steps
の一部として run
に使用されます。 一般的なコマンドには、以下のものがあります。
詳細については、「.NET CLI の概要」を参照してください
関連項目
.NET を使用する GitHub Actions の詳細については、次のリソースを参照してください。
.NET