feat(cli): mirror unityLicensingToolset across CLI surface

[frostebite]

What this is

Companion to game-ci/unity-builder#838 — adds unityLicensingToolset alongside the existing unityLicensingServer so users on Unity floating-license servers with multiple toolsets can target the correct one.

Background and the original investigation are in unity-builder#739: floating-license servers can host multiple toolsets, and without a toolset field in services-config.json the Licensing Client relies on the server-side default — which if missing or misconfigured causes Unity to silently fall through to a license that lacks the requested build target.

Changes

• BuildParameters: new field, initialized empty
• OrchestratorConfig (interfaces): new optional field
• CLI input mapper: new optional field
• build and activate yargs commands: new --unity-licensing-toolset flag
• CLI plugin adapter: passes through to BuildParameters

The actual injection into services-config.json lives in unity-builder (SetupShared). This PR is purely the CLI/config surface.

Are these opt-in? Backwards compatible?

Yes to both — the field defaults to empty everywhere, and is plumbed through unconditionally as an empty string when not provided. No behavior change for any existing flow.

entrypoint.sh — no change needed here

The companion runAsHostUser HOME/USER fix in unity-builder#838 is in dist/platforms/ubuntu/entrypoint.sh. The orchestrator's build-automation-workflow.ts copies that file from unity-builder's dist/ (ubuntuPlatformsFolder), so the fix flows through automatically once unity-builder is rebuilt.

Test plan

• yarn build clean (tsc passes)
• yarn test:ci — 887 passed, 4 pre-existing CLI integration timeouts unrelated to these changes (test names assert presence of existing flags only)
• Once unity-builder#838 lands, end-to-end verification on a real floating-license server with the --unity-licensing-toolset flag

🤖 Generated with Claude Code

[coderabbitai]

Warning

Rate limit exceeded

@frostebite has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 16 minutes and 6 seconds before requesting another review.

To continue reviewing without waiting, purchase usage credits in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: b732d470-baaa-4b16-bd07-dd20e1aba055

📥 Commits

Reviewing files that changed from the base of the PR and between 68bbf99 and 32e0032.

📒 Files selected for processing (6)

• src/cli-plugin/build-parameters-adapter.ts
• src/cli/commands/activate.ts
• src/cli/commands/build.ts
• src/cli/input-mapper.ts
• src/model/build-parameters.ts
• src/model/orchestrator/interfaces.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/issue-739-license-server-toolset

---

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 and usage tips.}

[frostebite]

Superseded by #26.

Architectural review (tracked in #25) concluded that orchestrator should not carry any Unity-specific licensing fields on its typed surfaces — its domain is dispatch + providers, not engine-specific licensing. PR #26 rips out the Unity licensing fields entirely, which makes adding unityLicensingToolset here unnecessary.

User-facing support for the toolset lives where the licensing concern actually belongs:

• fix: license server toolset input + runAsHostUser HOME/USER (closes #739) unity-builder#838 — adds the input + injects into services-config.json
• feat(cli): unityLicensingToolset option + relocate platform-setup to engine scope cli#50 — same on the CLI side

Orchestrator forwards the value opaquely via the existing coreParams: Record<string, any> plugin contract — no orchestrator-side surface needed.