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 イメージファイルへのパスを指定する必要があります。この場合は 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 doesn't affect the page_build event above
      - created

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

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

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

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

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

ワークフローでのアクションの参照

GitHub Actions でワークフローを作成するときに、さまざまなソースからアクションを参照できます。これらのアクションを使用して、ワークフロー内のタスクを自動化できます。ワークフローがアクションを参照できる主なソースを次に示します。

Docker Hub 上の発行済み Docker コンテナーイメージ
ワークフローは、Docker Hub で Docker コンテナーイメージとして発行されたアクションを参照できます。これらのアクションはコンテナー化され、アクションの実行に必要なすべての依存関係が含まれます。このようなアクションを使用するには、ワークフローステップの uses 属性で Docker イメージを指定します。例えば次が挙げられます。
```
steps:
  - name: Run a Docker action
    uses: docker://<docker-image-name>:<tag>
```
任意のパブリックリポジトリ
パブリックリポジトリでホストされているアクションは、ワークフロー内で直接参照できます。これらのアクションはだれでもアクセスでき、 uses 属性でリポジトリの名前とバージョン (Git ref、SHA、またはタグ) を指定することで使用できます。例えば次が挙げられます。
```
steps:
  - name: Use a public action
    uses: actions/checkout@v3
```

[!重要]

セキュリティを強化するには、 @v3などのタグだけでなく、アクションを参照するときに完全コミット SHA を使用します。
これにより、アクションが後で更新または変更された場合でも、ワークフローで常にまったく同じコードが使用されます。
例: uses: actions/checkout@c2c1744e079e0dd11c8e0af4a96064ca4f6a2e9e

ワークフローファイルと同じリポジトリ
ワークフローファイルと同じリポジトリに格納されているアクションを参照できます。この機能は、プロジェクトに固有のカスタムアクションに役立ちます。このようなアクションを参照するには、アクションのディレクトリへの相対パスを使用します。例えば：
```
steps:
  - name: Use a local action
    uses: ./path-to-action
```

詳細については、 GitHub Actions のセキュリティ強化ガイダンスを参照してください。

エンタープライズマーケットプレース
組織で GitHub Enterprise を使用している場合は、企業のプライベートマーケットプレースからのアクションを参照できます。これらのアクションは組織によってキュレーションおよび管理され、内部標準への準拠が保証されます。例えば：
```
steps:
  - name: Use an enterprise marketplace action
    uses: enterprise-org/action-name@v1
```

注

プライベートリポジトリ内のアクションも参照できますが、適切な認証とアクセス許可が必要です。
アクションを参照するときは、常にバージョン (Git ref、SHA、またはタグ) を指定して一貫性を確保し、予期しない変更を回避します。

詳細については、「ワークフローでのアクションの参照」を参照してください。

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

ランナーをジョブに関連付けられているものとして簡単に説明しました。ランナーは、単に GitHub Actions ランナーアプリケーションがインストールされているサーバーです。前のワークフローの例では、ジョブブロック内に 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 Actions には、GitHub プランと、ランナーが GitHub でホストされているかセルフホステッドであるかに応じて、いくつかの使用制限があります。使用制限の詳細については、GitHub ドキュメントの「Usage limits, billing, and administration」(使用制限、請求、管理) を参照してください。

GitHub ホステッドラージャーランナー

GitHub には、より多くのリソースを必要とするワークフロー用のより大きなランナーが用意されています。これらのランナーは GitHub でホストされ、標準ランナーと比較して CPU、メモリ、ディスク領域が増えます。リソースを集中的に使用するワークフローを効率的に処理し、要求の厳しいタスクに最適なパフォーマンスを確保するように設計されています。

ランナーのサイズとラベル

大規模なランナーは複数の構成で利用でき、多様なワークフロー要件を満たすために強化された vCPU、RAM、SSD ストレージが提供されます。これらの構成は、次のようなシナリオに最適です。

大規模なソースファイルを使用した大規模なコードベースのコンパイル。
統合テストやエンドツーエンドテストを含む、包括的なテストスイートの実行。
データ分析または機械学習タスク用の大規模なデータセットの処理。
複雑な依存関係または大きなバイナリ出力を含むアプリケーションを構築する。
ハイパフォーマンスシミュレーションまたは計算モデリングの実行。
ビデオエンコード、レンダリング、またはその他のマルチメディア処理ワークフローの実行。

大きなランナーを使用するには、ワークフローファイルの runs-on 属性で目的のランナーラベルを指定します。たとえば、16 個の vCPU と 64 GB の RAM を持つランナーを使用するには、 runs-on: ubuntu-latest-16core設定します。

jobs:
  build:
    runs-on: ubuntu-latest-16core
    steps:
      - uses: actions/checkout@v2
      - name: Build project
        run: make build

これらの大きなランナーは、標準の ubuntu-latest ランナーと同じプレインストールツールを含めることで、既存のワークフローとの互換性を維持します。

ラージャーランナーのランナーサイズの詳細については、GitHub のドキュメントを参照してください

ラージャーランナーの管理

GitHub には、大規模なランナーを効果的に管理し、最適なリソース使用率とコスト管理を確保するためのツールが用意されています。大規模なランナーを管理する主な側面を次に示します。

使用状況の監視

リポジトリまたは組織の設定の GitHub Actions の使用状況ページを使用して、大規模なランナーの使用状況を監視できます。このページでは、実行されるジョブの数、合計ランタイム、および関連するコストに関する分析情報を提供します。

アクセスの管理

大規模なランナーへのアクセスを制御するには、リポジトリまたは組織レベルのポリシーを構成します。この構成により、承認されたワークフローまたはチームのみがこれらの高リソースランナーを使用できるようになります。

コスト管理

より大きなランナーは、その使用量に応じて追加コストがかかります。コストを管理するには、次の推奨事項を検討してください。

大規模なランナーは、高いリソースを必要とするワークフローにのみ使用します。
ワークフローを最適化してランタイムを削減します。
課金の詳細を定期的に監視して、経費を追跡します。

ワークフローのスケーリング

ワークフローで大規模なランナーを頻繁に使用する必要がある場合は、次のようなスケーリング戦略を検討してください。

予測可能なワークロードにセルフホステッドランナーを使用する。
ワークフローを小さなジョブに分割して、標準ランナー間で負荷を分散します。

フィードバック

このページはお役に立ちましたか?