Unity Buildは成功した。でもログにはArgumentNullExceptionが4件残っていた

RicochetTanksのM0をBuildしたとき、結果だけ見れば成功だった。

VRChat SDKのBuildは終了。

Exit codeは0。

成果物も生成された。

でもUnity logを確認すると、ArgumentNullExceptionが4件残っていた。

SceneTemplateの保存callback由来だった。

ここで、

「Build成功」

と、

「エラーが一件もない」

を同じ意味にしてはいけないと分かった。

Artifactはちゃんと出ていた

対象のBuildでは、成果物が作られていた。

SDK側も終了している。

つまり、

「Buildできなかった」ではない。

一方で、logには例外が残る。

この2つは両立する。

だから報告では、

• Artifact生成: PASS
• Build process completion: PASS
• Log anomaly: あり

と分けて扱った。

Green / Redの1bitだけでは情報が足りない

CIや自動Buildでは、結果を1個のBoolへ落としたくなる。

成功。

失敗。

でも現実のToolchainはもっと曖昧。

今回のように、

• Exit code 0
• Artifactあり
• 一部callbackでException
• 実行対象とは無関係の可能性
• ただし原因未確定

という状態がある。

このとき全部をPASSにすると情報を失う。

全部をFAILにすると、実際には使えるArtifactまで止める。

「無視してよいException」も最初から無視しない

SceneTemplate側の例外だったから、RicochetTanks本体のUdon bugではない可能性は高い。

でも、

「関係なさそうだから無視」

で消すのも危ない。

Toolchainのversionが変わった。

Project状態が壊れた。

将来同じExceptionが別の失敗と組み合わさった。

そうなったとき比較できなくなる。

だからまず、存在したという事実を残す。

重要度の判断はその後。

Build結果を分解する

この経験以降、Buildの結果は少なくとも次のように分けた方が扱いやすい。

• Process exit
• Artifact existence
• Artifact size / hash
• Compile error
• Runtime smoke
• Log anomaly
• Human check
• NOT_RUN / NOT_CONFIRMED

全部を一つの「成功」に丸めない。

たとえばArtifactが出ても、importすると壊れるかもしれない。

Logが綺麗でも、人間が操作すると壊れるかもしれない。

自動化では特に重要

AgentやCIは、Exit codeを見るのが得意。

でもExit codeだけで意味を決めると、

「0だったので完全成功」

という強すぎる結論になりやすい。

RicochetTanksでは、実VRChatの試験でも、

• PASS
• FAIL
• NOT_CONFIRMED
• NOT_RUN

を分けた。

Buildでも同じ。

観測したもの以上の意味を結果へ足さない。

いまの結論

Buildが0で終わった。

Artifactもある。

それでもログにExceptionは存在した。

だから正確な報告は、

「Buildは成功した。ログはエラーなし、とは言えない」

になる。

少し面倒でも、この粒度を残した方が、後から自動化の結果を信用できる。