[bitsandfoxes]

The integration test build jobs now launch Unity two fewer times each, so they ask the floating license server for two fewer seats.

Every editor launch starts its own LicensingClient and acquires its own floating lease, and each acquisition can land in the "no valid Unity Editor license" retry loop. A build job launched the editor 4 times (3 for WebGL, Windows x86 and Windows Mono): add-sentry, configure-sentry, build #1, build #2. In the 30 days of green logs in the research, 65–86% of the build jobs had at least one license retry, and the mean retry sleep was ~9 min per job. Two of those four launches don't need an editor of their own:

• add-sentry.ps1 launched the editor only to call Client.Add("file:…"), which writes one line into Packages/manifest.json. In the sampled logs that launch waited 9:26 and 3:05 for a seat.
• configure-sentry.ps1 launched the editor only to run SentryEditorWindowInstrumentation.ConfigureOptions, which the first build launch can just as well do before it builds.

How it works now:

• add-sentry.ps1 writes "io.sentry.unity": "file:../../../test-package-release" into the manifest with pwsh. The path is relative to Packages/, which UPM supports, so it resolves the same on the host and inside the Docker container. The next launch (the build) resolves and imports the package before it runs -executeMethod. The -installSentry handler in the test project is gone. SentrySetup.cs only kept CommandLineArguments, so it's renamed after it.
• build-project.ps1 -ConfigureSentry passes -optionsScript IntegrationOptionsConfiguration -cliOptionsScript CliConfiguration [-dsn …] to the build launch, expects ConfigureOptions: SUCCESS and keeps the check that both option assets exist. Builder.BuildIl2CPPPlayer calls the same ConfigureOptions() (by reflection, since the project is also built without Sentry) and saves the assets before it builds. The second build reads them from disk, like it did after configure-sentry.
• The workflows drop the "Configure Sentry" step and pass -ConfigureSentry and SENTRY_DSN to the first build with Sentry. configure-sentry.ps1 is gone. integration-test.ps1 configures in the first build when it created the project, which is when it ran configure-sentry before.

Job	Editor launches before	After
Android, iOS, Linux, macOS, Windows	4	2
WebGL, Windows x86, Windows Mono	3	1

That's 52 → 24 launches per PR run (+1 per job on a build-without-Sentry cache miss), and 2 fewer for each of the extra build jobs main runs. ci/uaal-integration-tests touches the same "Configure Sentry" steps. Its External build doesn't need -ConfigureSentry, because the options are already saved by then.

Stacked on #2902.

CI evidence: run 40199161262 is green, including every Run job, which send events and assert symbol uploads with the options from the first build. In all 14 build jobs, add-sentry wrote io.sentry.unity: file:../../../test-package-release without a Unity launch, and the first build logged Builder: Configuring Sentry options → ConfigureOptions: SUCCESS. Editor launches with Sentry were 2 per job (1 for WebGL, Windows x86 and Windows Mono), 24 in total, against 52 in the previous run. The run also had a build-without-Sentry cache miss per job, since this PR changes files in its key, and on 6000.6 an existing exit-137 retry of that launch. Linux 6000.6 needed one rerun: its Native build succeeded, then Unity crashed on shutdown (signo:5 after Cleanup mono, exit 133). That launch is unchanged here, and it passed on the rerun.

Rebased onto #2907: run 40279729113 is green on the first attempt in 34.8 min.

🤖 Generated with Claude Code