1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@broken55

【Unity】GameCI v6 対応：GitHub Actions のクラウドビルドを最新化する

1
Posted at

はじめに

以前、【Unity】GameCIとGithubActionsを使ってクラウドビルド環境を構築する で、GameCI と GitHub Actions を使った Unity のクラウドビルドを紹介しました。

あれから GameCI 側の仕組みが大きく変わり、2026年9月に unity-builder v6.0.0 がリリースされています。この記事はその続きとして、既存の workflow を v6 に合わせるときに何が変わるかをまとめます。

サンプルは前回と同じリポジトリです。

公式ドキュメントの Getting Started はまだ @v4 の例が多いですが、Action 本体の最新メジャーは v6 です。この記事では実プロジェクトで動かした内容を優先しています。

GameCI のおさらい

GameCI は、ゲーム向けの CI/CD をオープンソースで提供しているプロジェクトです。Unity 向けには Docker イメージと GitHub Actions が中心で、GitLab CI や CircleCI にも対応しています。

GitHub 上では game-ci 配下に、ビルド用の unity-builder、テスト用の unity-test-runner、Docker イメージ、そして v6 の実体になる cli などが並んでいます。

前回の記事では、おおまかに次の流れでビルドしていました。

  1. Unity プロジェクトを GitHub に置く
  2. ライセンスを GitHub Secrets に登録する
  3. .github/workflows に YAML を書く
  4. Actions からビルドを実行する

この骨格は v6 でも同じです。変わるのは Action の中身 と、それに合わせて直す YAML です。

v6 で何が変わったか

unity-builder v6.0.0 の要点は次のとおりです。

  • Action は独自の Docker 制御をやめ、game-ci/cli の薄いラッパーになった
  • 入力・Secrets・プロジェクト構成は v5 からほぼそのまま使える
  • ローカルで game-ci CLI を叩いたときと、CI 上の Action が同じ経路になる

前回記事の @v4 から一気に飛ばすと、見た目の YAML は似ていても裏側が別物です。v6 では cliVersion という入力が増え、ここで CLI 本体のタグを指定します。

公式の Builder ドキュメント では、unityVersion のデフォルトは auto です。ProjectSettings/ProjectVersion.txt から Unity バージョンを読むので、エディタを上げたときに YAML を直し忘れる事故を減らせます。

workflow の差分（前回記事 → v6）

前回の Windows ビルドは、だいたいこんな指定でした。

uses: game-ci/unity-builder@v4
env:
  UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
  UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
  UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
with:
  targetPlatform: StandaloneWindows64
  unityVersion: 2022.3.0f1

今回サンプルを動かした構成は次のとおりです。他のパッケージに関しても最新にアップデートしています。

項目 前回（記事時点） 今回
unity-builder @v4 @v6
Unity バージョン指定 2022.3.0f1 を直書き auto（ProjectVersion.txt）
CLI なし cliVersion: v0.1.69 にピン留め
Personal ライセンス UNITY_LICENSE + メール + パスワード メール + パスワード（後述）

完成形の build.yml

サンプルの Windows ビルドは次の内容です。LFS キャッシュの考え方は、公式の Getting started にある「Simple example with Git LFS」と同じです。

name: Run the Windows build
on:
  workflow_dispatch: {}
jobs:
  build:
    name: Run the Windows build
    runs-on: ubuntu-latest
    steps:
      - name: Check out my unity project.
        uses: actions/checkout@v7
      - name: Create LFS file list
        run: git lfs ls-files -l | cut -d' ' -f1 | sort > .lfs-assets-id

      - name: Restore LFS cache
        uses: actions/cache@v6
        id: lfs-cache
        with:
          path: .git/lfs
          key: ${{ runner.os }}-lfs-${{ hashFiles('.lfs-assets-id') }}

      - name: Git LFS Pull
        run: |
          git lfs pull
          git add .
          git reset --hard

      - name: Set outputs
        id: vars
        run: echo "sha_short=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT

      - uses: actions/cache@v6
        with:
          path: Library
          key: Library-${{ hashFiles('Assets/**', 'Packages/**', 'ProjectSettings/**') }}
          restore-keys: |
            Library-

      - name: Run the Windows build
        uses: game-ci/unity-builder@v6
        env:
          UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
          UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
        with:
          targetPlatform: StandaloneWindows64
          unityVersion: auto
          cliVersion: v0.1.69

      - name: Upload the Windows Build
        uses: actions/upload-artifact@v7
        with:
          name: Build-${{ steps.vars.outputs.sha_short }}
          path: build

ポイントだけ補足します。

unityVersion: auto

Builder の unityVersion は、デフォルトが auto です。プロジェクトの ProjectSettings/ProjectVersion.txt を読むので、Unity 6（例: 6000.3.9f1）に上げても YAML を触らずに済みます。

明示的にバージョンを書く場合は、Hub に出る文字列そのものが必要です。2022.3.16 のように末尾の f1 を落とすと解決できません。v6 ではこの指定が CLI の --engineVersion に渡ります。

cliVersion はピン留めする

v6 は実行時に game-ci/cli のバイナリを落とします。未指定だと Action 側が入れる CLI が古いままになり、前回記事の @v4 から @v6 に上げただけではビルドが落ちます。実際に cliVersion を書かずに動かしたところ、CLI v0.1.64 が入り、次のように失敗しました。

Installing game-ci CLI v0.1.64 via https://raw.githubusercontent.com/game-ci/cli/v0.1.64/scripts/install.sh
...
/tmp/game-ci-cli-cache/v0.1.64/game-ci build --targetPlatform=StandaloneWindows64 --engineVersion=6000.3.9f1 ...
...
[ERROR] Error: There was an error building the project. Please read the logs for details.
Error: Build failed with exit code 1

cliVersion に新しいタグを明示すると通ります。本稿執筆時点の最新は v0.1.69 でした。CLI 側の Releases を見て更新してください。

ライセンス：公式手順と、v6 で実際に起きたこと

公式の Activation では、ライセンス種別ごとに Secrets が分かれています。

  • Personal: UNITY_LICENSE（.ulf の中身）+ UNITY_EMAIL + UNITY_PASSWORD
  • Professional: UNITY_SERIAL + UNITY_EMAIL + UNITY_PASSWORD
  • License Server: unityLicensingServer にサーバー URL

GameCI はメールやパスワードを保管しません。ビルド／テストのたびに Unity をアクティベートするために使います。パスワードに記号が入っていると失敗しやすい、という注意も Builder にあります。

前回記事でも書いたとおり、Personal は Manual Activation で .ulf を取れなくなっています。公式も Unity Hub で Personal を追加し、OS ごとのパスから .ulf を拾う手順です。

Windows: C:\ProgramData\Unity\Unity_lic.ulf
Mac: /Library/Application Support/Unity/Unity_lic.ulf
Linux: ~/.local/share/unity3d/Unity/Unity_lic.ulf

ここからが v6 で実測した差分です。手元の Hub で作った .ulf を UNITY_LICENSE に入れると、GitHub-hosted runner（Docker）では次のようなログが出ます。

The license file's machine binding doesn't match this machine - falling back to activating with the Unity account (UNITY_EMAIL/UNITY_PASSWORD) instead.

.ulf は発行したマシンの ID に紐づきます。CI のコンテナとは ID が違うため、ファイルは無視してアカウント認証に落ちる動きです。今回のサンプルでは、このフォールバック後にビルドが通ったので、UNITY_LICENSE を外して UNITY_EMAIL / UNITY_PASSWORD だけに揃えました。

ただし公式ドキュメントは、Personal でも UNITY_LICENSE を残す前提のままです。2FA やエディタ版、ライセンス種別によってはアカウント認証だけでは失敗します。Pro ならもともと UNITY_SERIAL が本筋です。

「公式どおり残す」か「今回のようにメール／パスワードだけにする」かは、自分のアカウントで一度通してから決めるのが安全です。

応用：任意のビルド関数はこれまでどおり

前回の応用編（Builder.Build に -message を渡す）は、v6 でも同じ入力です。

- name: Run the Windows build
  uses: game-ci/unity-builder@v6
  env:
    UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
    UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
  with:
    targetPlatform: StandaloneWindows64
    unityVersion: auto
    cliVersion: v0.1.69
    buildMethod: Builder.Build
    customParameters: -message MyCustomParameters

buildMethod は Assets/Editor 配下（または Editor Assembly）の static メソッドを指します。環境変数は Unity 側に届かないので、値を渡すなら customParameters を使います。詳細は Builder の configuration options です。

つまずきやすいところ

  • 公式サイトのバージョン表記
    game.ci のドキュメント切替がまだ v4 を current としていることがあります。Action の最新は GitHub の unity-builder Releases を見てください。
  • workflow が見えない
    前回と同じく、GitHub Actions はデフォルトブランチ前提です。別ブランチだけで YAML を足すと、Actions タブに出ないことがあります。
  • IL2CPP
    公式の Getting Started にあるとおり、IL2CPP はビルド対象と runner OS を揃える必要があります。Linux runner から Windows IL2CPP を出す、といった組み合わせは別途確認してください。
  • Linux 成果物の拡張子
    v5 以降、StandaloneLinux64 はデフォルトで .x86_64 が付きます。以前の拡張子なしに戻すなら linux64RemoveExecutableExtension: true です。

うまくいかないときは、公式の Common issues と、Discord 経由のコミュニティが近道です。

まとめ

前回の「GameCI + GitHub Actions でクラウドビルド」は、v6 でも十分使えます。ただし Action は CLI のラッパーになったので、次を合わせておくと安心です。

  1. game-ci/unity-builder@v6 にする
  2. unityVersion: auto にする
  3. cliVersion を CLI のリリースタグに固定する
  4. ライセンスは公式手順を読んだうえで、自分の環境で .ulf が本当に使われているかログを見る

GameCI 自体は MIT のオープンソースで、ドキュメントやイメージ、Action が github.com/game-ci にまとまっています。バージョンが飛びやすい領域なので、YAML をコピーするときはドキュメントの @v4 例をそのまま使わず、Release のタグを確認してください。

参考

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?