LeavaTailの日記

LeavaTailの日記

Linuxエンジニアを目指した技術者の備忘録

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

はじめに

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)と共有化して実行する。

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

     $ docker build -t kbuild .
    
  2. Dockerコンテナでカーネルをビルドする。

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

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

テストスクリプトの作成

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

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

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

[f:id:LeavaTail:20200713001155p:plain]
プロジェクトのソフトウェアワークフロー

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

GitHub Actionsとの連携

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

  1. プロジェクトトップページのActionsを選択する。
    [f:id:LeavaTail:20200712222313p:plain]
    GitHub Actionsボタン
  2. 今回はDocker imageのリポジトリなのでDocker imageの「Set up this workflow」を選択する。(自分のリポジトリに似たテンプレートがなければ、「set up a workflow yourself」で一から作成する。)
    [f:id:LeavaTail:20200712223605p:plain]
    workflowsのテンプレートを選択する
  3. templeteからworkflowsのひな形が生成されるので、必要に応じて修正する。
    [f:id:LeavaTail:20200712224759p:plain]
    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を契機としているので、すぐに作成したテストが走る。

f:id:LeavaTail:20200712231800p:plain
workflowsの結果確認

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

f:id:LeavaTail:20200712233236p:plain
ジョブの実行結果を確認する

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

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

f:id:LeavaTail:20200713001226p:plain
GitHub Actionsと連携後のソフトウェアワークフロー

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

おわりに

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

この記事はあくまで導入のためのフローを書き記したものであり、GitHub Actionsはまだ多彩の機能を兼ね備えている。
ドキュメントを充実しており、導入の敷居も低いのでGitHub Actionsを導入して、プロジェクトの品質を向上させていきたい。

参考