GitHub Actionsで既存リポジトリのテストを自動化する

概要
はじめに
準備
テストスクリプトの作成
GitHub Actionsとの連携
おわりに
変更履歴
参考

概要

既存のソフトウェアに対して、GitHub Actionによるテストの自動化を導入する。

はじめに

GitHubではパブリックリポジトリであれば GitHub Actions という機能が無料に使用することができる

GitHub Actions では、世の中のCI/CDサービスと同様にソフトウェアワークフロー (例えば、Masterブランチにマージする前に用意しておいたテストを流し、テストが通ったらマージを許可するなど) を簡単に自動化することができる。

GitHub Actionsは利用料金がお手軽(プライベートリポジトリでも利用時間が2000分/月)といった点や、GitHubのサービスの一つでもある点から高い統合性がみられる。
また、ソフトウェアワークフローのテンプレートも幅広いパターンが用意されており、導入の敷居が低いといった点もみられる。

そこで、本記事はソフトウェアワークフローが自動化されていないリポジトリに、GitHub Actionsを導入するまでの手順を書き留めた。

準備

下記のリポジトリを例にGitHub Actionsと連携させる手順をまとめる。

github.com

このプロジェクトは、様々なアーキテクチャ(x86/arm/arm64)用でLinux カーネルをビルドするためのDockerイメージを管理している。
Dockerイメージの利用方法は、ホスト環境にあるlinuxトップディレクトリ(${PWD}/linux)をコンテナ内のワーキングディレクトリ(/work)と共有化して実行する。

Dockerfileからイメージを生成する。

$ docker build -t kbuild .

Dockerコンテナでカーネルをビルドする。

$ docker run --rm --name=kbuild -v ${PWD}/linux:/work -it kbuild make

これまで、このプロジェクトはテストを用意しておらず、実行のたびに問題が見つかっていた。

テストスクリプトの作成

GitHub Actionsと連携するにあたって、手動で実施するテストを設計・実装するところから始める。

このプロジェクトでは、Linux カーネルのビルド環境を構築するDockerイメージであり、考えられるテストパターンは莫大に存在する。
今回は、LTSのカーネル *1 のみを対象として、Linux カーネルがビルドできるかどうかを確認する。

テストの全体像は次に示す。

テストに必要なtarballをkernel.orgからダウンロードする。
プロジェクトが提供しているDockerfileからDockerイメージを作成し、コンテナを起動させる。
コンテナ内でカーネルがビルドできるかどうかテストする。

GitHub Actionsとの連携

プロジェクトのソフトウェアフローが決まったので、GitHub Actionsと連携させていく。

プロジェクトトップページのActionsを選択する。
GitHub Actionsボタン
今回はDocker imageのリポジトリなのでDocker imageの「Set up this workflow」を選択する。(自分のリポジトリに似たテンプレートがなければ、「set up a workflow yourself」で一から作成する。)
workflowsのテンプレートを選択する
templeteからworkflowsのひな形が生成されるので、必要に応じて修正する。
workflowsのEdit画面

今回のプロジェクトでは、下記のようなworkflowを作成した。

name: Docker Image CI                          # ワークフローの名前。ページに表示される
        
on:                                            # masterブランチへのpush/PRを契機とする
  push:        
    branches: [ master ]        
  pull_request:        
    branches: [ master ]        
        
jobs:        
        
  build:                                       # ジョブのID
        
    runs-on: ubuntu-latest                     # ジョブを実行するマシンの環境
        
    steps:                                     # 一連のタスクとして下記を実行する
    - uses: actions/checkout@v2                # リポジトリからチェックアウトする 
    - name: Obtain LTS kernel                  
      run: ./tests/00_init.sh                  # tarballを取得・展開する
    - name: Execute the Docker Container
      run: ./tests/01_build.sh                 # Dockerコンテナの起動
    - name: Execute the Docker Container
      run: ./tests/10_allnobuild.sh            # カーネルのビルド

上記のファイルを作成後、Masterブランチにコミットすると、作成したworkflowsが有効になる。
また、今回のworkflowはmasterへのpushを契機としているので、すぐに作成したテストが走る。

ジョブ(build)の結果を確認する。

今回は設定しなかったが、actions/upload-artifact@v1と指定すると成果物を残すことができる。(artifactsで確認可能? )

下記にGitHub Actionsと連携させた後の概要図は下記のようなものになった。

ユーザが対象のリポジトリに対してPushかPull Requestを投げたとき(on:以下の指定より)、GitHubがあらかじめ用意してあるjobを実行する。
GithubがUbuntuの仮想マシンを立ち上げ(runs-on: ubuntu-latestより)、下記のタスクを実行していく。
Ubuntu 仮想マシン上にリポジトリをチェックアウトする。(actions/checkout@v2)
指定されたスクリプトを実行し、Docker Imageが適切かどうか検証する。