この記事は Akatsuki Advent Calendar 2020 21日目の記事です。
前日は Ruby on Rails 6.1 の水平シャーディング対応 & Octopusからの移行事例でした。
アカツキ人事がハートドリブンに書く Advent Calendar 2020 もあるのでそちらもぜひ。

はじめに

去年の Advent Calendar で GitHub ActionsでUnityのAndroid, iOSビルドをやってみるという記事を書きました。
あれから1年が経ち、自分が所属しているプロジェクトで実際に GitHub Actions を使った CI 環境を構築し運用しているので、その事について書いていきたいと思います。

GitHub Actions ってなに？という方や GitHub Actions の細かい導入方法を知らない方は前回の記事を読んでもらえると嬉しいです！！

全体の流れ

初めに全体の流れを図示した画像をお見せします。

大まかに説明をすると

GitHub Actions がイベントを検知して .github/workflows にあるワークフローファイルに記述されている処理を self-hosted で登録している PC で実行
ワークフローファイルでリポジトリの更新や環境変数の定義し build.sh を実行
build.sh で Unity から iOS, Android 向けのビルドを行い、 fastlane で xcodeproj → ipa へのビルドや DeployGate へのアップロードを行なっています

ワークフローファイルについて

まずはワークフローファイルの内容は以下のような内容です（一部書き換えを行ったりしています）

name: Build

on:
  schedule:
     - cron: "0 3 * * 1-5"
  workflow_dispatch:
    inputs:
      clean:
        description: 'Clean build.'
        required: true
        default: 'false'
      delete_output:
        description: 'Delete output file.'
        required: true
        default: 'true'
      upload:
        description: 'Upload to deploygate.'
        required: true
        default: 'false'
  pull_request:
    branches: [ development ]

env:
  UNITY_VERSION: 2019.4.0f1
  SLACK_URL: ${{secrets.SLACK_URL}}
  CLEAN: ${{github.event.inputs.clean}}
  DELETE_OUTPUT: ${{github.event.inputs.delete_output}}
  UPLOAD: ${{github.event.inputs.upload}}

jobs:
  buildAndroid:
    # The type of runner that the job will run on
    runs-on: [self-hosted, macOS, for-Android]

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
    # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
    - name: Checkout client
      uses: actions/checkout@v2
      with:
        path: client
        clean: 'false'
        lfs: 'true'
        submodules: 'true'
        token: ${{secrets.PERSONAL_ACCESS_TOKEN_FOR_GITHUB}}

    - name: Checkout resource
      uses: actions/checkout@v2
      with:
        repository: resource
        path: resource
        lfs: 'true'
        token: ${{secrets.PERSONAL_ACCESS_TOKEN_FOR_GITHUB}}

    # Runs a single command using the runners shell
    - name: Build Android
      run: |
        if [ ${{github.event_name}} == "pull_request" ]; then
          sh client/CI/build.sh -p Android -c false -d true -u false
        fi
        if [ ${{github.event_name}} == "schedule" ]; then
          sh client/CI/build.sh -p Android -c false -d true -u true
        fi
        if [ ${{github.event_name}} == "workflow_dispatch" ]; then
          sh client/CI/build.sh -p Android -c ${CLEAN} -d ${DELETE_OUTPUT} -u ${UPLOAD}
        fi
      env:
        # fastlane 向けのパスワードや Apple のアカウント情報など渡したい機密情報を環境変数として渡す

  buildIOS:
    runs-on: [self-hosted, macOS, for-iOS]

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
    # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
    - name: Checkout client
      uses: actions/checkout@v2
      with:
        path: client
        clean: 'false'
        lfs: 'true'
        submodules: 'true'
        token: ${{secrets.PERSONAL_ACCESS_TOKEN_FOR_GITHUB}}

    - name: Checkout resource
      uses: actions/checkout@v2
      with:
        repository: resource
        path: resource
        lfs: 'true'
        token: ${{secrets.PERSONAL_ACCESS_TOKEN_FOR_GITHUB}}

    - name: Build iOS
      run: |
        if [ ${{github.event_name}} == "pull_request" ]; then
          sh client/CI/build.sh -p iOS -c false -d true -u false
        fi
        if [ ${{github.event_name}} == "schedule" ]; then
          sh client/CI/build.sh -p iOS -c false -d true -u true
        fi
        if [ ${{github.event_name}} == "workflow_dispatch" ]; then
          sh client/CI/build.sh -p iOS -c ${CLEAN} -d ${DELETE_OUTPUT} -u ${UPLOAD}
        fi
      env:
        # fastlane 向けのパスワードや Apple のアカウント情報など渡したい機密情報を環境変数として渡す

ではそれぞれ解説をしていきます。
全部は解説しないので漏れてしまったものはドキュメントを読んでください。
なお、解説の内容は 2020/12 時点の内容となっています。

on

on: はワークフローをトリガーするGitHubイベントの名前です。
プロジェクトの状況に合わせて適宜変えてください。
ここでは schedule（定期実行）, workflow_dispatch(手動実行), pull_request(PRが作成、更新された時に実行)の3種類を使っています。
workflow_dispatch では入力を定義できるので、任意のパラメータを設定することが可能です。
また、デフォルト値の設定も可能なので入力がなければデフォルト値を使う、ということがもできます。

env

それぞれの Job で共通で使う環境変数を定義します。
なお、機密情報は Secrets を利用しワークフローファイルに直接書かないようにしましょう。

runs-on

iOS と Android で実行する Runner を分けたい場合もあると思います。
その際には iOS, Android それぞれのラベルを用意することでジョブを実行するマシンを選択することができます。
ラベルは Self-hosted runners のページから設定できます。

actions/checkout@v2

リポジトリを取得、更新します。
複数のブランチを取得することもできます。詳細はこちらで確認してください。

Build

build.sh にパラメータを渡して実行しています。
ここは説明する必要はないと思うので飛ばします。

大まかにですが、以上でワークフローファイルの説明を終わりにします。

その他 Tips

Unity のバージョンをワークフローファイルに直接記述する

Unity のバージョンはワークフローファイルに直接書きます。
こうすることでバージョンアップ対応の際にそのブランチだけ Unity のバージョンを変更する、ということができるためです。

GitHub から手動で実行する

workflow_dispatch を定義すると
このように GitHub の Actions から実行できるようになります。もちろんパラメータの設定も可能です。
これで手動実行もできるようになります！便利ですね！~~(最近まで知らなかった)~~

GitHub Actions の Runner を複数登録する

自分が所属しているプロジェクトでは self-hosted として動かしている PC が一台あり、この PC から Runner として4つ登録しています。
そして Runner にラベルを付けることで、 iOS, Android のビルド処理を分けて実行させています。
こうすることでプラットフォーム切替を発生させずに高速化しています。

まとめ

去年の記事を書いてからプロジェクトに導入する機会があったため、実際に導入して運用しそこで行なった工夫を書いてみました。
GitHub Actions で Unity のビルドを行おうとしている方の参考になれば幸いです。
今年は AWS の Mac インスタンスも発表され、Unity のビルド環境がまた一歩進みましたね。移行したい。