Understanding GitHub Actions

概要

GitHub Actions は、ソフトウェア開発ライフサイクル内のタスクを自動化するのに役立ちます。 GitHub Actions はイベント駆動型で、指定されたイベントが発生した後に一連のコマンドを実行できます。 たとえば、誰かがリポジトリのPull Requestを作成するたびに、ソフトウェアテストスクリプトを実行するコマンドを自動的に実行できます。

この図は、GitHub Actions を使用してソフトウェアテストスクリプトを自動的に実行する方法を示しています。 イベントは、ジョブを含むワークフローを自動的にトリガーします。 次に、ジョブはステップを使用して、アクションが実行される順序を制御します。 これらのアクションは、ソフトウェアテストを自動化するコマンドです。

GitHub Actions のコンポーネント

以下は、ジョブを実行するために連動する複数の GitHub Actions コンポーネントのリストです。 これらのコンポーネントがどのように相互作用するかを確認できます。

ワークフロー

ワークフローは、リポジトリに追加する自動化された手順です。 ワークフローは 1 つ以上のジョブで構成されており、スケジュールまたはイベントによってトリガーできます。 ワークフローを使用して、GitHub でプロジェクトをビルド、テスト、パッケージ、リリース、またはデプロイできます。

イベント

イベントは、ワークフローをトリガーする特定のアクティビティです。 たとえば、誰かがコミットをリポジトリにプッシュした場合、あるいはIssueもしくはプルリクエストが作成された場合、GitHubからアクティビティを発生させることができます。 リポジトリディスパッチ webhook を使用して、外部イベントが発生したときにワークフローをトリガーすることもできます。 ワークフローのトリガーに使用できるイベントの完全なリストについては、ワークフローをトリガーするイベントを参照してください。

ジョブ

ジョブは、同じランナーで実行される一連のステップです。 デフォルトでは、複数のジョブを含むワークフローは、それらのジョブを並行して実行します。 ジョブを順番に実行するようにワークフローを設定することもできます。 たとえば、ワークフローにコードのビルドとテストという2つのシーケンシャルなジョブを持たせ、テストジョブをビルドジョブのステータスに依存させることができます。 ビルドジョブが失敗した場合は、テストジョブは実行されません。

ステップ

ステップは、ジョブでコマンドを実行できる個々のタスクです。 ステップは、アクションまたはシェルコマンドのいずれかです。 ジョブの各ステップは同じランナーで実行され、そのジョブのアクションが互いにデータを共有できるようにします。

アクション

アクションは、ジョブを作成するためにステップに結合されるスタンドアロンコマンドです。 アクションは、ワークフローの最小のポータブルな構成要素です。 独自のアクションを作成することも、GitHub コミュニティによって作成されたアクションを使用することもできます。 ワークフローでアクションを使うには、それをステップとして含めなければなりません。

ランナー

ランナーは、GitHub Actionsランナーアプリケーションがインストールされているサーバーです。 GitHub がホストするランナーを使用することも、自分でランナーをホストすることもできます。 ランナーは、使用可能なジョブをリッスンし、一度に 1 つのジョブを実行し、進行状況、ログ、および結果を GitHub に返します。 GitHub ホストランナーは Ubuntu Linux、Microsoft Windows、macOS に基づいており、ワークフローの各ジョブは新しい仮想環境で実行されます。 GitHub ホストランナーについては、GitHub ホストランナーについて」を参照してください。 別のオペレーティングシステムが必要な場合、または特定のハードウェア設定が必要な場合は、自分のランナーをホストできます。 セルフホストランナーの詳細については、「自分のランナーをホストする」を参照してください。

サンプルワークフローを作成する

GitHub Actionsは、YAML 構文を使用して、イベント、ジョブ、およびステップを定義します。 これらの YAML ファイルは、コードリポジトリの .github/workflows というディレクトリに保存されます。

コードがプッシュされるたびに一連のコマンドを自動的にトリガーするサンプルワークフローをリポジトリに作成できます。 このワークフローでは、GitHub Actions がプッシュされたコードをチェックアウトし、ソフトウェアの依存関係をインストールして、bats-v を実行します。

1. リポジトリに、ワークフローファイルを保存するための .github/workflows/ ディレクトリを作成します。
2. .github/workflows/ ディレクトリに、learn-github-actions.yml という名前の新しいファイルを作成し、次のコードを追加します。

   name: learn-github-actions
   on: [push]
   jobs:
     check-bats-version:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v2
         - uses: actions/setup-node@v2
           with:
             node-version: '14'
         - run: npm install -g bats
         - run: bats -v
   

3. これらの変更をコミットして、GitHub リポジトリにプッシュします。

これで、新しい GitHub Actions ワークフローファイルがリポジトリにインストールされ、別のユーザがリポジトリに変更をプッシュするたびに自動的に実行されます。 ジョブの実行履歴の詳細については、「ワークフローのアクティビティを表示する」を参照してください。

ワークフローファイルを理解する

YAML 構文を使用してワークフローファイルを作成する方法を理解しやすくするために、このセクションでは、導入例の各行について説明します。

name: learn-github-actions

on: [push]

jobs:

check-bats-version:

  runs-on: ubuntu-latest

  steps:

    - uses: actions/checkout@v2

    - uses: actions/setup-node@v2
      with:
        node-version: '14'

    - run: npm install -g bats

    - run: bats -v

ワークフローファイルの視覚化

この図では、作成したワークフローファイルと、GitHub Actions コンポーネントが階層にどのように整理されているかを確認できます。 各ステップは、単一のアクションまたはシェルコマンドを実行します。 ステップ 1 と 2 は、ビルド済みのコミュニティアクションを使用します。 ステップ 3 と 4 では、ランナーで直接シェルコマンドを実行します。 ワークフローのビルド済みアクションの詳細については、「アクションの検索とカスタマイズ」を参照してください。

ジョブのアクティビティを表示する

ジョブの実行が開始されると、の視覚化グラフが表示され、GitHub での各ステップのアクティビティが表示されます。

1. GitHub Enterprise Serverで、リポジトリのメインページにアクセスしてください。

2. リポジトリ名の下でActions（アクション）をクリックしてください。

3. 左サイドバーで、表示するワークフローをクリックします。

4. [Workflow runs] で、表示する実行の名前をクリックします。

5. ジョブ名をクリックして、各ステップの結果を確認します。

次のステップ

GitHub Actions について詳しくは、「アクションの検索とカスタマイズ」を参照してください。

To understand how billing works for GitHub Actions, see "About billing for GitHub Actions".

サポートへの連絡

たとえば構文、GitHubホストランナー、アクションの構築など、ワークフローの設定に関して何か支援が必要な場合は、GitHub Community SupportのGitHub Actionsカテゴリで既存のトピックを探してみるか、新しいトピックを開始してください。

GitHub Actionsについてのフィードバックもしくは機能リクエストがあるなら、それらをGitHub Actionsのフィードバックフォームで共有してください。

あなたの利用方法、もしくは意図する利用方法が利用制限のカテゴリに当てはまるかどうかに関わらず、以下のいずれかの場合はyour site administratorに連絡してください。

• アカウントに間違った制約が課されていると思われる場合
• たとえばユニークIDのような予想外のエラーに、アクションの実行時に遭遇した場合
• 既存の動作が期待される、ただし必ずしもドキュメント化されてはいない動作と矛盾するような状況に遭遇した場合