GitHub Actionsを動かしてみよう_はじめてのCI/CD

はじめに

開発チームのメンバーに、GitHub Actionsについて説明することがありました。

Gitコマンドを利用したことがある人はそれなりにいますが、GitHub Actionsを利用したことがない、言葉はよく聞くが使い方は判らない、といった人が割といることに気付きました。

いい機会なのでGitHub Actionsについて整理したいと思います。

GitHub Actionsを使うと、これまで人が手作業で行っていた処理を、GitHub上で自動実行できるようになります。

例えば、次のような処理です。

• プログラムのテスト
• コードの静的解析
• アプリケーションのビルド
• AWSやAzureへのデプロイ
• Dockerイメージの作成
• 定期的なバッチ処理

今回は、簡単なWorkflowを作成し、

GitHubへpushしたらGitHub Actionsが自動実行される

ところまでを整理しました。

GitHub Actionsとは

GitHub Actionsとは、GitHubが提供しているワークフロー自動化機能です。

あるシステムのプログラムを開発しているとします。通常は次のように人がコマンドを実行していたとします。

GitHub Actionsを利用すると、これらの処理をGitHubへのpushなどをきっかけに自動実行できます。テスト、ビルド、デプロイ（オレンジのオブジェクト）はGitHub Actionsが自動実行します。

GitHub Actionsでは、このような自動処理を「Workflow」として定義します。WorkflowはYAML形式のファイルに記述します。GitHub公式ドキュメントでは、Workflowを「1つ以上のJobから構成される、自動化可能なプロセス」としています。

CI/CDとは

GitHub Actionsを理解するうえで、よく登場するのが「CI/CD」です。

CIは、Continuous Integration　の略で、日本語では「継続的インテグレーション」と呼ばれます。例えば、プログラムをGitHubへpushしたときに、

などを自動実行します。

コードを変更するたびに自動チェックできるため、問題を早い段階で発見できます。

一方、CDは文脈によって、

• Continuous Delivery
• Continuous Deployment

の意味で使われます。

簡単に考えると、下記のようなイメージです。

CI
コードが問題ないことを確認する

CD
問題のないコードを実際の環境へ届ける

今回は、本格的なCI/CDは作りません。下記のような小さなWorkflowを作ります。

GitHub Actionsの基本構造

GitHub Actionsでは、次のような構造で処理を定義します。

• Workflow
  GitHub Actions全体の処理です。
  例えば、Pythonのテストを実行するという一連の処理を1つのWorkflowとして定義できます。
• Job
  Workflowの中で実行する処理のまとまりです。
  たとえば、テストとビルドのように複数のJobを作れます。
• Step
  Jobの中で実際に実行する個々の処理です。
  例えば、ソースコード取得、Pythonインストール、pytest実行のようなStepを作れます。

今回はJobを1つ、Stepも1つだけ作ります。

Workflowファイルを配置する場所

GitHub ActionsのWorkflowファイルは、リポジトリ内に下記のディレクトリを配置します。

.github/workflows/

今回、下記ファイルを作ります。

hello-actions.yml

リポジトリ構成は次のようになります。

sample-project
│
└─ .github
    └─ workflows
        └─ hello-actions.yml

GitHub Actionsは .github/workflows ディレクトリ内に配置されたYAMLファイルをWorkflowとして認識します。

最初のWorkflowを作成する

hello-actions.yml を作成し、次の内容を記述します。短いWorkflowですが、GitHub Actionsの基本要素がすべて入っています。

name: Hello GitHub Actions

on:
  push:

jobs:
  hello:
    runs-on: ubuntu-latest

    steps:
      - name: Hello
        run: echo "Hello GitHub Actions"

name

最初のnameはWorkflowの名前です。

name: Hello GitHub Actions

GitHubのActions画面では、この名前が表示されます。Workflowの処理自体には大きく影響しませんが、後から見たときに分かりやすい名前を付けておきます。

on

on は、いつWorkflowを実行するかを指定します。

on:
  push:

今回は push を指定しているため、GitHubリポジトリへpushされたときにWorkflowが実行されます。イメージは下記となります。

GitHub Actionsでは、push以外にも、さまざまなイベントをきっかけにWorkflowを実行できます。

pull_request
schedule
workflow_dispatch
release
issues

jobs

jobs 以下に、Workflowで実行するJobを定義します。

jobs:

今回は、helloというJobを1つ作っています。

jobs:
  hello:

hello という名前は自由に変更できます。

例えば、

jobs:
  test:

や、

jobs:
  build:

などでも構いません。

runs-on

どの環境でJobを実行するかを指定しています。

runs-on: ubuntu-latest

GitHub Actionsでは、処理を実行するマシンをRunnerと呼びます。

今回指定している、下記はGitHubが用意しているUbuntu環境です。

ubuntu-latest

イメージとしては、下記となります。GitHub ActionsではUbuntu以外にもWindowsやmacOSのRunnerを利用できます。

steps

ここにJobの中で実行する処理を順番に記述します。

steps:

今回はStepを1つだけ作っています。

- name: Hello
  run: echo "Hello GitHub Actions"

name はStepの名前です。

run には、実際に実行するコマンドを記述します。

つまり今回はUbuntu上で、下記のコマンドを実行します。

echo "Hello GitHub Actions"

Workflow全体をもう一度確認する

ここまでを整理します。

name: Hello GitHub Actions

on:
  push:

jobs:
  hello:
    runs-on: ubuntu-latest

    steps:
      - name: Hello
        run: echo "Hello GitHub Actions"

日本語にすると、ほぼ次の意味です。

Workflow名
「Hello GitHub Actions」

GitHubへpushされたら

helloというJobを開始する

Ubuntu上で実行する

HelloというStepを実行する

echo "Hello GitHub Actions"
を実行する

GitHub ActionsのYAMLは最初は難しく見えますが、一つずつ意味を確認すると、それほど複雑ではありません。

GitHubへpushする

Workflowファイルを作成したらGitHubへpushします。

例えば次のように実行します。

git add .

git commit -m "Add first GitHub Actions workflow"

git push

pushが完了すると、下記のように処理が自動的に開始されます。

GitHub Actionsの実行結果を確認する

GitHubの対象リポジトリを開きます。

1. 上部メニューから、「Actions」を選択します。
2. 今回作成した、「Hello GitHub Actions」というWorkflowが表示されます。
3. 正常終了すると、緑色のチェックマークが表示されます。
   
4. helloをクリックすると、各Stepの実行結果を確認できます。
5. Helloのログを開くと、Hello GitHub Actionsという文字列が出力されていることを確認できます。
   

これで最初のGitHub Actionsは成功です。

GitHub Actionsはどこで動いているのか

ここで一度、仕組みを整理します。

今回自分のPCで実行したのは、下記コマンドまでです。

git push

echo "Hello GitHub Actions" は自分のPCでは実行していません。

処理の流れは、下記となります。

GitHub Actionsを使うことで、自分のPCとは別の環境で自動的に処理を実行できます。ここが重要なポイントです。

わざと失敗させてみる

Workflowが失敗するとどうなるのかも確認してみます。

次のように変更します。

name: Hello GitHub Actions

on:
  push:

jobs:
  hello:
    runs-on: ubuntu-latest

    steps:
      - name: Hello
        run: |
          echo "Hello GitHub Actions"
          exit 1

exit 1 は処理を異常終了させます。

変更したら、再び、pushします。

git add .

git commit -m "Test workflow failure"

git push

今度はGitHub Actionsが赤いエラー表示になります。

ログを確認すると、exit 1 によってStepが失敗していることを確認できます。

CI/CDでは、この「失敗を検知できる」ことが重要です。

例えば将来、

Pull Request
     ↓
GitHub Actions
     ↓
pytest
     ↓
テスト失敗
     ↓
GitHub Actionsも失敗

とすることで、問題があるコードを早い段階で発見できます。

今回覚えておきたい用語

登場した用語を整理します。

まとめ

GitHub Actionsの最初の一歩として、GitHubへのpushをきっかけにWorkflowを実行しました。

ポイントは次の通りです。

• GitHub Actionsでは処理をWorkflowとして定義する
• WorkflowはYAML形式で記述する
• .github/workflows にWorkflowファイルを配置する
• on で実行するタイミングを指定する
• Jobの中にStepを定義する
• Runner上でコマンドが実行される
• Actions画面から実行結果とログを確認できる
• コマンドが失敗するとWorkflowも失敗する

今回のWorkflowでは、まだ文字列を表示しただけです。

次回は、GitHub Actions上で実際にPythonのコードを実行し、

Ruff → mypy → pytest

によるコード品質チェックと自動テストを組み込んでいきます。

これによって、GitHub Actionsが単なる「コマンドの自動実行」から、本格的なCIへ変わっていきます。

以上です。