CI/CDを実現するツール「GitHub Actions」を使ってみよう

はじめに

第12回でCI/CDパイプラインとは何か、CI/CDを実現するツールについて解説しました。CI/CDがなぜ必要なのか、どのような効果があるのかは、先の記事でご理解いただけたのではないでしょうか。

今回は、CI/CDを実現するツール「GitHub Actions」の使い方を解説します。

GitHub Actionsとは

GitHub ActionsはGitHubが提供しているCI/CDプラットフォームです。JenkinsやGitLabのようにセルフホストする必要がなく、CircleCIやTravis CIのようにソースコードリポジトリとは別のプラットフォームを契約する必要はありません。GitHubにアカウントがあれば誰でも簡単に使い始められます。

GitHub Actionsを実行するにはワークフローファイルが必要です。ワークフローファイルとはYAMLフォーマットのテキストファイルで、ワークフローファイルをリポジトリに含めることでGitHub Actionsを使用できます。

GitHub Actionsはジョブを指定されたOS上で実行します。指定できるOSはLinux、Windows、macOSです。これらのOSで実行できるコマンドをジョブとして指定できます。コマンドが不得意でもジョブの組み立ては非常に簡単です。GitHub ActionsにはActionと呼ばれる処理の塊がGitHub Marketplaceで公開されており、ジョブから呼び出すことで効率的にワークフローを構築できます。

Actionを使用するには注意点も存在します。それはActionを誰でも自由に公開できるという点です。Actionの開発者が企業や著名なエンジニアであれば安心ですが、誰が作成したのか分からないActionには悪意のあるコードが含まれているかもしれません。

少しでも安全にActionを使用するには、Actionを検索するときにMarketplaceの左側ナビゲーションメニューから「Verified Creator」を指定します。Verified Creatorはパブリッシャーが特定の条件を満たしている場合に付加されます。ただし、GitHubがActionの中身まで分析しているわけではない点に注意してください。あくまでも野良のActionよりは出所がはっきりしており、このバッジ(詳細は「Marketplaceバッジについて」を参照)を手にいれるためコードがしっかりメンテされているであろうということです。Actionを使用する際はActionのチェンジログやイシュー、プルリクエストなどをよく読んで、慎重に検討してください。

GitHub Actionsの料金設定

GitHub Actionsはパブリックリポジトリから使用する場合は無料です。しかし、プライベートリポジトリから使用する場合にはアカウントのプランによって無料利用枠が設けられています。

また、ランナーと呼ばれるジョブを実行するマシンのOSによって、実行時間の倍率が異なります。

ランナーのOSがLinuxの場合、ジョブを1分間実行したら無料利用枠から1分間の利用時間が消費されます。Windowsの場合はジョブを1分間実行すると無料利用枠からは2分間消費されます。そのため、例えばFreeプランを利用している場合にはWindowsランナーを使用すると月に1,000分しか実行できないことになります。macOSは10倍なので月に200分しか実行できません。無料利用枠と使用するOSを考慮してプランを選定しましょう。

無料利用枠を超過した場合にはジョブを実行できなくなるため、追加で実行時間を購入します。自動で課金されることはありません。さらに詳しく知りたい場合は公式ドキュメント「GitHub Actionsの課金について」を参照してください。

GitHub Actionsの使用方法

GitHub Actionsを使用するには、GitHubアカウントとリポジトリが必要です。下記のドキュメントを参考にアカウントとリポジトリを作成し、手元のマシンにクローンしてください。

• GitHubアカウントの作成
• 新しいリポジトリの作成
• リポジトリをクローンする

GitHub Actionsを使用するには、リポジトリ直下に.github/workflowsディレクトリと、ワークフローを定義するファイルを作成してリポジトリにコミットします。

$ mkdir -p .github/workflows
$ touch .github/workflows/actions.yaml

上記の例では、ワークフローを定義するファイル名を「actions.yaml」としました。ワークフローファイルは拡張子が「.yml」か「.yaml」であればファイル名はどのようなものでも問題ありません。GitHub Actionsはファイルごとにワークフローを実行するので、どのようなワークフローなのか、どのような処理が行われるのか、名前から分かりやすいものを付けると良いでしょう。

ワークフローファイルに下記のコードを記述します。

# ワークフロー名を「example workflow」に設定
name: example workflow

# リポジトリにPushされたらActionsを実行する
on: push

jobs:
  # ジョブ名を「echo」に設定
  echo:
    # ランナーOSをUbuntuの最新に設定
    runs-on: ubuntu-latest
    steps:
      # ジョブ内で実行する処理を列挙
      # uses: はActionとして公開されている処理を呼び出す
      # actions/checkoutを実行してランナーOS上にリポジトリをクローンする
      - uses: actions/checkout@v4
      # run: はシェルコマンドを実行する
      - run: echo 'hello world'

今回使用しているコードは最小限の処理しか記述していません。例えばonではプルリクエストが作成されたときや特定のブランチにコミットされたとき、特定のファイルに変更が加えられたときなどを指定できます。設定できる内容を詳しく知りたい場合は公式ドキュメント「ワークフロー構文」を参照してください。

コードをGitHub上にPushします。

$ git add .github/workflows/actions.yaml
$ git commit -m 'add actions' .github/workflows/actions.yaml
$ git push origin main

GitHubでActionsが実行されたか見てみましょう。リポジトリの上部にある「Actions」タブから確認できます。

Actionsの画面

左側の赤枠で囲われている部分を選択するとワークフローの中身が確認できます。「example workflow」となってる部分がワークフロー名です。ワークフローファイルの上部で設定したname: example workflowと一致します。新たに別のワークフローが追加されると項目が増えていくので、ワークフローには分かりやすい名前を付けておきましょう。

中央の赤枠で囲われている部分が実行されたワークフローです。「add actions」となっている部分がコミットメッセージになります。このワークフローを選択するとワークフローで何が実行され、どのような結果になったのかを確認できます。

ワークフローの画面

赤枠で囲われている部分がジョブです。ジョブの左側にステータスが表示されておりて、緑のチェックマークは成功を表しています。ジョブが失敗したら赤のバツマークになるため、どのジョブが失敗しているのか、ここから判断できます。

ジョブを選択するとジョブの中身を確認できます。

ジョブの実行画面

中央の黒い画面がジョブの実行履歴です。上から順に処理されています。通常は>マークの横に実行したジョブが表示されているだけですが、赤枠で囲われている部分をクリックすることで詳細な情報が展開されます。ジョブが失敗した際などに展開して、詳細情報を確認すると良いでしょう。

GitHub Actionsのデバッグ

GitHub Actionsはランナーマシンでジョブを実行しますが、このマシンにはSSHなどでログインできません。ジョブの実行履歴は実行画面からしか確認できませんが、もしジョブの実行画面からデバッグに必要な情報が手に入らなければデバッグログを有効にすると良いでしょう。

実際にエラーが発生するジョブをリポジトリにコミットしてみます。

name: example workflow

on: push

jobs:
  echo:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          repository: ${{ github.repository }}-not-found
      - run: echo 'hello world'

このコードではactions/checkoutにパラメータを設定しています。actions/checkoutはrepositoryというパラメータを指定することで指定されたリポジトリをランナー上にクローンします。${{ github.repository }}は今回使用しているリポジトリ名にアクセスするための変数です。末尾に-not-foundという文字列を追加して存在しないリポジトリを指定しました。

修正したコードをリポジトリにPushします。

$ git commit -m 'add fail job' .github/workflows/actions.yaml
$ git push origin main

Actionsタブからワークフローを見ると、ジョブが失敗していることが分かります。

失敗したジョブの実行画面

この画面からはデバッグに必要な情報が読み取れなかったとしましょう。そこで赤枠内の「Re-run jobs」をクリックし、ジョブを再実行してみます。ジョブの再実行には「Re-run all jobs」「Re-run failed jobs」の2つの選択肢があります。前者は全てのジョブを再実行するのに対し、後者は失敗したジョブだけを再実行します。どちらを選んでも問題ありません。ジョブが複数あった場合、最初から順に実行していかないといけない場合は前者を、失敗したジョブだけで実行できるのであれば後者を選択すると良いでしょう。

どちらかを選択すると再実行画面が出力されます。

再実行画面

この画面の左下にある「Enable debug logging」にチェックを入れることでデバッグログを出力できます。

デバッグログを有効化した実行画面

紫色で##[debug]と書かれている部分がデバッグログです。デバッグログを有効にする前には分からなかった情報が表示されるようになったため、なぜ期待通りに動かないのか悩んだらデバッグログを有効にしてみましょう。

おわりに

今回は、GitHub Actionsの使い方について解説しました。GitHub Actionsは柔軟で高機能なため、ほんの一例しか解説できませんでしたが、公式ドキュメント(GitHub Actionsドキュメント)が充実しているため、そちらを熟読すると良いでしょう。ワークフロー同士、ジョブ同士を連携できたり、プルリクエストを処理できたりなど、GitHubを使った開発を楽にしてくれる設定や、面白い使い方などが解説されています。