fix: detect Unity 6 projects (6000.M.PPl# version scheme)

[frostebite]

Reported on Discord: engine auto-detection ("Unity project detection failed") for Unity 6 projects, even on v0.1.51. The report named the exact spot - `UnityVersionDetector#versionPattern` - and it was right.

Root cause

`versionPattern` was `/20\d{2}.\d.\w{3,4}|3/`, which had two separate bugs:

• `20\d{2}` only matches the legacy YYYY-scheme major version. Unity 6's "6000.M.PPl#" scheme (e.g. `6000.0.78f1`) starts with `6000`, not `20xx`, so it never matched at all.
• The trailing `|3` alternation - regex alternation has very low precedence - made the whole pattern effectively `(20\d{2}.\d.\w{3,4})|(3)`. Once the first branch failed (as it always did for Unity 6), `.match()` fell through to matching a bare literal `"3"` anywhere in the file - which the string `"6000.0.78f1"` itself contains.

So this wasn't just "detection failed": a real Unity 6 project silently "detected" as version `"3"", which would have gone on to build a nonsense Docker image tag with zero indication of the real cause. Reproduced both failure modes by running the exact pre-fix code against real `ProjectVersion.txt` content:

```
OLD CODE result for Unity 6: "3"
```

This is the actual engine auto-detection entry point (`UnityVersionDetector.isUnityProject`/`getUnityVersion`, called from `unity-plugin.ts`) - not a secondary path - so every Unity 6 user running plain `game-ci build` without an explicit `--engine` override was affected.

Fix

Anchor extraction to Unity's own `m_EditorVersion: ` key instead of a floating version-shaped substring search. `\d+` (not a fixed `20\d{2}`) covers both the legacy and Unity 6 schemes - the same fix `RunnerImageTag.versionPattern` already carries for a different caller (validating an explicit `--engineVersion` override rather than parsing `ProjectVersion.txt`; see #154, unity-builder#847).

Test coverage

Existing coverage was minimal (2 tests, neither exercising Unity 6 - exactly how this shipped unnoticed) and is preserved here, plus new coverage for: the Unity 6 scheme, `m_EditorVersionWithRevision` not being mistaken for `m_EditorVersion`, the old bug's bare-`"3"` false positive not recurring, and the real `isUnityProject`/`getUnityVersion` path end-to-end against an actual `ProjectVersion.txt` fixture already in this repo.

Verification

• `tsc --noEmit` clean.
• New test file: 9/9 pass.
• Full `bun test ./src`: same 2 pre-existing failures (an unrelated `form-data` module resolution issue) as clean `main` - confirmed by diffing against a stash of this fix. No regressions.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

[coderabbitai]

Warning

Review limit reached

Next included review available in 54 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 43cbc69b-8100-443c-ab92-997ea26df833

📥 Commits

Reviewing files that changed from the base of the PR and between 92c21d4 and 8e94ec4.

📒 Files selected for processing (2)

• src/middleware/engine-detection/unity-version-detector.test.ts
• src/middleware/engine-detection/unity-version-detector.ts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}