`test` command needs a Docker-based mode before unity-test-runner can convert to invoke-cli

[frostebite]

Context

unity-activate (#111) and unity-builder (#844) have both been converted from importing @game-ci/unity-engine-core as an in-process library to actually shelling out to game-ci/cli as a subprocess - the real actions-invoke-cli architecture (game-ci/roadmap#11 workstream 2). unity-test-runner (#310) is the third and last, still on the old library-import approach - and unlike the other two, it can't be safely converted yet.

The gap

cli test and unity-test-runner are not the same feature with different plumbing - they're architecturally different:

• cli test (src/command/test/unity-test-command.ts) runs Unity's own official, still-experimental unity test CLI (docs.unity.com/en-us/unity-cli) directly on the local machine. No Docker at all.
• unity-test-runner is entirely Docker/Hub-image-driven, and has a real feature surface cli test doesn't touch: package-mode testing (packageMode, scopedRegistryUrl, registryScopes), code coverage (coverageOptions, coveragePath output), GitHub Checks API reporting (githubToken, checkName), artifactsPath output, and the same docker resource/registry options build has (dockerCpuLimit, containerRegistryRepository, etc.).

Converting unity-test-runner to invoke cli test as-is would silently drop all of that for anyone using it today - the same class of regression closed for build in #70, just much bigger.

What's needed

A Docker-based mode for cli test (or a new command) that actually matches unity-test-runner's real surface - closer in scope to build (which already has the Docker orchestration, docker resource/registry options) than to today's local-unity test-CLI-only test command. Rough shape, not a final design:

• Docker-driven test execution (reusing Docker.run/RunnerImageTag, same as build)
• Package-mode support (testing a Unity package instead of a full project)
• Coverage options and a coverage output path
• GitHub Checks API reporting (or an equivalent that doesn't hardcode a GitHub-only DX into cli, if this is meant to also serve local/non-Actions use)

Not scoping this further or attempting an implementation here - it's a materially bigger effort than #70 and deserves its own design pass, not something to rush blind.

🤖 Generated with Claude Code

[frostebite]

Scoped this properly by reading unity-test-runner's actual implementation rather than guessing at the surface. Posting the concrete design here since that's what was blocking this — not implementing the full thing in this pass, for reasons below.

What's actually involved

cli's dist/platforms/ has zero test-execution scripts today — no run_tests.sh/run_tests.ps1 equivalent to build.ps1/build.sh. This has to be built, not adapted. unity-test-runner's own implementation (which handles the same problem) is ~2,600 lines across:

• src/model/results-parser.ts (158 lines) — parses Unity's NUnit XML test-results format
• src/model/results-check.ts (162 lines) — validates results, handles partial/malformed XML (this is the file the coverageEnabled/results-check fixes from earlier this session touched)
• src/model/results-report.ts (58 lines) + results-meta.ts (118 lines) — GitHub Checks API reporting
• src/model/input.ts (259 lines) — the full option surface (packageMode, scopedRegistryUrl, registryScopes, coverageOptions, coveragePath, checkName, artifactsPath, etc.)
• Platform scripts (run_tests.sh/run_tests.ps1) that actually invoke Unity.exe -runTests inside the container and mount results out

Proposed shape (mirrors build, not test)

A new command (test-docker, or test --docker — naming TBD) that:

1. Reuses Docker.run/RunnerImageTag/PlatformSetup exactly as build does — same image resolution, same container mount pattern.
2. Ships dist/platforms/{ubuntu,windows}/run_tests.{sh,ps1}, ported from unity-test-runner's real scripts (not reinvented) since those are already battle-tested against real Unity test output across many editor versions.
3. Ports results-parser.ts/results-check.ts/results-report.ts as src/model/unity-test/*.ts, with the coverage/package-mode/Checks-API options added to a new TestOptions (parallel to BuildOptions).

Why not implemented here

This is real, correctness-sensitive surface (NUnit XML parsing edge cases, GitHub Checks API semantics) with no existing test coverage in cli to build on — shipping an unverified first pass risks silently breaking test reporting for anyone who'd migrate, which is worse than the status quo of unity-test-runner staying on its current (working) implementation a while longer. The activate/build migrations in this session all had the benefit of comparing against real CI failures to converge on — this one doesn't have that safety net without first landing something.

Recommend treating this as its own tracked implementation effort (probably 3-5 focused PRs: platform scripts → results parsing → Checks reporting → command wiring), not a single PR. Leaving open — happy to pick up the first slice (Docker orchestration + basic results parsing, no coverage/Checks API yet) as a separate PR if that's useful.