GitHub Actions で開発タスクを自動化する方法

  • 10 分

ここでは GitHub Actions とワークフローについて説明します。 使用できるアクションの種類と、それらの場所について説明します。 また、これらのアクションの種類の例を参照し、ワークフローに適合させる方法についても確認します。

GitHub によって構想からデプロイまでの時間を短縮

GitHub は、開発者や DevOps エンジニアのチームがアプリケーションを迅速にビルドしてデプロイできるように設計されています。 GitHub にはこれを可能にする多くの機能がありますが、一般的に、次の 2 つのカテゴリのいずれかに分類されます。

  • 通信: GitHub を使用すると、開発者のチームはソフトウェア開発プロジェクトに関する情報を簡単に伝達できます (pull request のコード レビュー、GitHub の問題、プロジェクト ボード、wiki、通知など)。
  • 自動化: チームで GitHub Actions を使うと、統合から配信、デプロイまで、ソフトウェア開発プロセスのすべてのステップでワークフローを自動化できます。 さらに、pull request にラベルを追加し、古い issue と pull request の確認も自動化できます。

これらの機能を組み合わせると、何千もの開発チームが、初期の構想からデプロイまでにかかる時間を効果的に減らすことができます。

ワークフローの自動化を使用して開発時間を短縮する

このモジュールでは、自動化に焦点を当てます。チームが自動化を利用して、一般的な開発とデプロイのワークフローを完了するのにかかる時間を短縮する方法を学習しましょう。

コードを記述した "後"、意図した目的でコードを確実に使用できるようになる前に、実行する必要があるすべてのタスクを考慮してください。 組織の目標によっては、次の 1 つ以上のタスクを実行する必要があります。

  • コードがすべての単体テストに合格するようにする
  • コード品質とコンプライアンスのチェックを実行して、ソース コードが組織の標準を満たしていることを確認する
  • 既知のセキュリティ問題について、コードとその依存関係を確認する
  • (場合によっては) 複数の共同作成者からの新しいソースを統合するコードをビルドする
  • ソフトウェアが統合テストに合格するようにする
  • 新しいビルドのバージョンを作成する
  • 適切なファイルシステムの場所に新しいバイナリを配信する
  • 1 つまたは複数のサーバーに新しいバイナリをデプロイする
  • これらのいずれかのタスクが成功しなかった場合、解決のために問題を適切な個人またはチームに報告する

課題は、信頼性が高く、一貫性があり、維持可能な方法で、これらのタスクを実行することです。 これは、ワークフローの自動化に最適なジョブです。 GitHub に既に依存している場合は、GitHub Actions を使用してワークフローの自動化を設定することをお勧めします。

GitHub Actions とは

GitHub Actions は、GitHub のソフトウェア開発ワークフローでタスクを自動化するためのパッケージ化されたスクリプトです。 開発者が一定の間隔で、または手動で新しいソース コードを特定のブランチにチェックインするたびに、組織のニーズを満たす複雑なワークフローをトリガーするように、GitHub Actions を構成できます。 その結果、信頼性が高く維持可能な自動化されたワークフローとなり、開発時間が大幅に短縮されます。

GitHub Actions がある場所

GitHub Actions は、.yml データ形式に準拠するスクリプトです。 各リポジトリには、最初のスクリプトの設定をすばやく簡単に開始する方法を提供する [アクション] タブがあります。 優れた出発点になると考えられるワークフローがある場合は、[構成] ボタンを選択してスクリプトを追加し、ソース yml の編集を開始するだけです。

[単純なワークフロー] と、このワークフローを設定するためのボタンが表示されている、GitHub Actions の [アクション] タブのスクリーンショット。

ただし、[アクション] タブにあるこれらの GitHub Actions 以外にも、次の操作を実行できます。

  • GitHub Marketplace で GitHub Actions を検索する。 GitHub Marketplace では、ワークフローを拡張するツールを検出して購入することができます。
  • オープンソース プロジェクトを検索する。 たとえば、GitHub Actions 組織は、使用可能な GitHub Actions を含む多くの一般的なオープンソース リポジトリを備えています。
  • 独自の GitHub Actions を最初から作成する。 また、必要に応じて、それらをオープンソースにすることも、GitHub Marketplace に公開することもできます。

オープンソースの GitHub Actions を使用する

多くの GitHub Actions はオープンソースであり、それらを使いたいと考える誰でも使用できます。 ただし、どのオープンソース ソフトウェアでも同様に、プロジェクト内で使用する前に、それらを慎重に確認する必要があります。 README、倫理規定、contributing ファイル、issue テンプレートなど、オープンソース ソフトウェアで推奨されるコミュニティ標準と同様に、GitHub Actions を使用する場合は、以下の推奨事項に従うことができます。

  • アクションの action.yml ファイルの入力や出力を確認し、コードで、実行すると示されている内容が実行されていることを確認します。
  • アクションが GitHub Marketplace に存在するかどうかを確認します。 これは、アクションが有効になるために、GitHub Marketplace に存在する必要がない場合でも適切なチェックです。
  • アクションが GitHub Marketplace で検証されているかどうかを確認します。 これは、GitHub でこのアクションの使用が承認されていることを意味します。 ただし、それでもそれを使用する前に確認しておく必要があります。
  • Git 参照、SHA、またはタグを指定して、使用しているアクションのバージョンを含めます。

GitHub アクションの種類

GitHub Actions には、コンテナー アクション、JavaScript アクション、複合アクションの 3 種類があります。

コンテナー アクションでは、環境はアクションのコードの一部になります。 これらのアクションは、GitHub がホストする Linux 環境でのみ実行できます。 コンテナー アクションは、多数の言語をサポートします。

JavaScript アクションでは、コードに環境は含まれません。 これらのアクションを実行する環境を指定する必要があります。 クラウドまたはオンプレミスの VM でこれらのアクションを実行できます。 JavaScript アクションでは、Linux、macOS、Windows 環境がサポートされます。

複合アクションでは、1 つのアクション内で複数のワークフロー ステップを組み合わせることができます。 たとえば、この機能を使用して、複数の実行コマンドを 1 つのアクションにバンドルし、バンドルされたコマンドをそのアクションを使用する 1 つのステップとして実行するワークフローを作成できます。

GitHub アクションの構造

リポジトリの git チェックアウトを実行するアクションの例を次に示します。 このアクション、actions/checkout@v1 は、ワークフローの 1 ステップの一部です。 このステップでは、チェックアウトされた Node.js コードもビルドします。次のセクションで、ワークフロー、ジョブ、およびステップについて説明します。

steps:
  - uses: actions/checkout@v1
  - name: npm install and build webpack
    run: |
      npm install
      npm run build

コンテナー化されたコードを実行するために、コンテナー アクションを使用する場合を考えます。 アクションは次のようになります。

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
    MY_NAME:
      description: "Who to greet"
      required: true
      default: "World"

runs:
    uses: "docker"
    image: "Dockerfile"

branding:
    icon: "mic"
    color: "purple"

inputs セクションに注目してください。 ここでは、MY_NAME という変数の値を取得します。 この変数は、このアクションを実行するワークフローで設定されます。

runs セクションでは、uses 属性で docker を指定することに注意してください。 このときに、Docker イメージ ファイルのパスを指定する必要があります。 この例では、Dockerfile としています。 ここでは、Docker について詳述しませんが、詳細については、「Docker コンテナーの概要」モジュールを参照してください。

最後のセクション branding では、GitHub Marketplace でアクションをパーソナライズします (公開することを決定した場合)。

アクション メタデータの完全な一覧については、「GitHub Actions のメタデータ構文」参照してください。

GitHub Actions ワークフローとは

GitHub Actions ワークフローは、ソフトウェア開発ライフ サイクルのタスク (GitHub Actions を含む) を自動化するためにリポジトリで設定するプロセスです。 ワークフローを使用すると、任意のプロジェクトを GitHub でビルド、テスト、パッケージ化、リリース、およびデプロイできます。

ワークフローを作成するには、GitHub リポジトリの .github/workflows ディレクトリにある .yml ファイルにアクションを追加します。

この後の演習では、ワークフロー ファイル main.yml は次のようになります。

name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: ./action-a
      with:
        MY_NAME: "Mona"

on: 属性に注目してください。 これは、このワークフローを実行するタイミングを指定するための "トリガー" です。 ここでは、リポジトリへのプッシュ イベントがあると実行をトリガーします。 on: push のような 1 つのイベント、on: [push, pull_request] のようなイベントの配列、またはイベント構成マップを指定できます。マップは、ワークフローをスケジュールするか、ワークフローの実行を特定のファイル、タグ、またはブランチの変更に制限します。 マップは次のようになります。

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration does not affect the page_build event above
      - created

イベントは、種類を指定しない限り、そのイベントのすべてのアクティビティの種類に対してトリガーされます。 イベントとそのアクティビティの包括的な一覧については、GitHub ドキュメントの「ワークフローをトリガーするイベント」を参照してください。

ワークフローには少なくとも 1 つの "ジョブ" が必要です。 ジョブは、"ランナー" に関連付けられたワークフローのセクションです。 ランナーは GitHub でホストするかセルフホストにすることができ、ジョブはマシンまたはコンテナーで実行できます。 ランナーは、runs-on: 属性を使用して指定します。 ここでは、ubuntu-latest でこのジョブを実行するようにワークフローに指示しています。

各ジョブには、完了するステップがあります。 この例では、リポジトリをチェックアウトするためにアクション actions/checkout@v1 を使用しています。 興味深いのは、uses: ./action-a 値です。これは action.yml ファイルで作成するコンテナー アクションへのパスです。 action.yml ファイルの内容は、上記の「GitHub Actions とは」セクションで確認しました。

このワークフロー ファイルの最後の部分では、このワークフローの MY_NAME 変数値を設定します。 コンテナー アクションによって MY_NAME という入力を取得したことを思い出してください。

ワークフロー構文の詳細については「GitHub Actions のワークフロー構文」を参照してください。

GitHub ホステッド ランナーとセルフホステッド ランナー

ランナーをジョブに関連付けられているものとして簡単に説明しました。 ランナーは、単に GitHub Actions ランナー アプリケーションがインストールされているサーバーです。 前のワークフローの例では、jobs ブロック内に runs-on: ubuntu-latest 属性がありました。これにより、ワークフローに、このジョブが、ubuntu-latest 環境で実行されている GitHub ホステッド ランナーを使用して実行されることを伝えていました。

ランナーに関しては、次の 2 つのオプションから選択できます。GitHub ホステッド ランナーまたはセルフホステッド ランナー。 GitHub ホステッド ランナーを使用する場合、各ジョブは、定義した GitHub ホステッド ランナーの種類によって指定された仮想環境の新しいインスタンスで実行されます (runs-on: {operating system-version})。 セルフ ホステッド ランナーでは、セルフホステッド ラベル、そのオペレーティング システム、およびシステム アーキテクチャを適用する必要があります。 たとえば、Linux オペレーティング システムと ARM32 アーキテクチャを使用したセルフホステッド ランナーは、runs-on: [self-hosted, linux, ARM32] のようになります。

ランナーの種類ごとに利点がありますが、GitHub ホステッド ランナーは、ワークフローを実行するより迅速で簡単な方法ですが、オプションは限られます。 セルフホステッド ランナーは、独自のカスタム ローカル環境でワークフローを実行するための高度に構成可能な方法です。 セルフホステッド ランナーは、オンプレミスまたはクラウドで実行できます。 また、セルフホステッド ランナーは、大きなジョブを実行するための多くの処理能力やメモリを備えたカスタム ハードウェア構成を作成する、ローカル ネットワークで使用可能なソフトウェアをインストールする、GitHub ホステッド ランナーで提供されていないオペレーティング システムを選択するために使用することもできます。

GitHub Actions の使用制限

GitHub プランと、ランナーが GitHub ホステッドかセルフホステッドかによって、GitHub Actions にはいくつかの使用制限があります。 使用制限の詳細については、GitHub ドキュメントの「Usage limits, billing, and administration」(使用制限、請求、管理) を参照してください。