Key information
Unity’s CI/CD article proposes using Unity CLI as a consistent entry point for testing, building and provisioning Editors. It addresses pipelines that currently depend on hard-coded executable paths, prepared runner images and studio-maintained wrapper scripts.
A job can install an explicit Editor and platform modules or use --allow-install with the version recorded in ProjectVersion.txt. That makes the project’s required environment part of the pipeline, which is particularly useful when a runner starts clean or a branch upgrades Unity.
Tests can produce NUnit XML reports, while builds can keep an existing project-specific C# build method. CI platforms still handle repository checkout, secrets, caches and artifact publishing; the CLI standardizes the Unity-facing operations rather than replacing those systems.
The article also recommends treating credentials and licensing as job-lifetime resources. Reports and logs should survive a failed run, and license return belongs in teardown that executes even after a failure. Using the same Unity commands locally and in CI can make failures easier to reproduce.
