GitHub Actions を使ったリグレッションテスト

Researcher の尾川です。今回はソルバーのテストがテーマです。

ユーザーから「なにもしてないのにこわれました」と言われてしまう状況の予防や早期発見には、テストが重要です（参考画像はもちろん持ってます）。

なにもしてないのにこわれました！！

ぱちょこん
<イラスト：店長 里一磨＞https://t.co/mGkqPfgvtd pic.twitter.com/Z1dWUKljlw

— ekotロボ (@ekot_ROBOT) 2017年7月20日

当社のソルバーでは現在、PRマージ後の短時間のテストと、週一回のリグレッションテストを実施しています。 前者は更新した Docker イメージがきちんと機能するか（push してよいか）を決めるためのもので、本稿では詳細は割愛します。 後者は次のような目的をまとめて実現するものです。

• 処理時間を含むスケーラビリティのチェック
• その時点の結果の保管
  • データセットの規模によっては半日や1日かかる処理について git bisect 的な検証は現実的ではないので、そのヒントになり得るキャッシュ
• 週末遊んでいる社内のマシンの有効活用
• （長期的に俯瞰することで進歩を実感できる？）

最近までこのテストは自作の Python スクリプトをドライバーとして cron から開始していましたが、端的にいうと「やりたいことがすべて終わらない」をきっかけとした不満や手間が生じやすい状況でした。

• 週末が過ぎても終わらない
  • 対象を減らす → それはちょっと…
  • 処理するマシンを増やす → 今の実行方法では厳しい
  • 強制終了させる → いろいろな状況を想定しないと最大数百GBの残骸が残る

そこで、GitHub Actions の schedule トリガーによって抜本的な解決を図りました。 Runner は、一定以上のスペックが要求されるため GitHub のものでは不十分なのと、もともと遊休リソースの活用も目的だったことから、社内のマシン2台に self-hosted runner を導入しました。

Workflow の内容（push はデバッグ用）

on:
  push:
    paths:
      # ...
  schedule:
    - cron: '2 23 * * 5' # Saturday 8:02 JST

jobs:
  shared-startup:
    runs-on: gpu
    steps:
      - id: get-id
        run: echo "value=ci-develop-$(date +%Y%m%d-%H%M%S)" >> $GITHUB_OUTPUT
    outputs:
      id: ${{ steps.get-id.outputs.value }}
      imagerootdir: /sandbox/path/to/image
      resultrootdir: /sandbox/path/to/result/${{ steps.get-id.outputs.value }}
  weekly-challenge:
    needs: shared-startup
    runs-on: ${{ matrix.runs-on }}
    continue-on-error: true
    strategy:
      matrix:
        include:
          - dataset: dataset1
            runs-on: gpu
            event_names: [push, schedule]
          - dataset: dataset2
            runs-on: gpu
            event_names: [schedule]
          # ...
    container:
      image: ssm:develop
      volumes:
        - /path/to/storage:/sandbox
      options: --gpus all
    steps:
      - uses: actions/checkout@v3
      - uses: ./.github/actions/run_ssm
        if: contains(matrix.event_names, github.event_name)
        with:
          imagedir: ${{ needs.shared-startup.outputs.imagerootdir }}/${{ matrix.dataset }}/images
          resultdir: ${{ needs.shared-startup.outputs.resultrootdir }}/${{ matrix.dataset }}

これにより、まだ全てのケースが完璧というわけではありませんが、次のような変化を実感しているところです。

• 2台をフル活用することで、これを機にテスト対象を増やしたにもかかわらずおおむね終わるようになった
  • さらに増やすのも容易なほか、逆に何らかの理由で1台使えない状況でも（完了は望めないが）ある程度カバーできる
• Slack 通知が最初の一回以外はスレッド化され、週末の QoL を改善した

ただ、GitHub Actions としての時間制限に起因する課題があるのは確かなので、もう少し改善したい思いはあります。

• 1日以上キューされたままだと強制的にスキップされてしまう
  • キューされないように matrix をいくつかの job に分割することで改善できそう
• 1日以上実行するとトークンの期限が切れる（らしい）
  • 該当するデータセットは現状1つだけなので当面は気にしない

以上、最近の取り組みに関する紹介でした！

202304_skymatix_engineer from skymatixHR

www.slideshare.net