CI: compile the Kotlin plugin and run the unit tests

[oristanovic]

Two coverage gaps found while chasing a compile failure on #142. Base is MOBILE-3815 so the in-flight release work picks these checks up immediately.

What CI missed

Area	Before	After
C# (AirshipSDK.dll)	Compiled	Compiled
Unit test assembly	Compiled, never run	Run (EditMode)
Kotlin (unity-plugin)	Not compiled at all	Compiled
Swift (Assets/Plugins/iOS)	Not compiled	Still not compiled — see below

The Kotlin gap is the bigger of the two. No AAR is checked in, and the existing Unity player build never invokes the unity-plugin gradle module, so every Kotlin change to date reached review without a compiler ever looking at it. #142 changes the Android event pump, trackScreen's nullability and the live-update payload shape — none of that is currently verified by anything.

The tests have existed and been compiled for a while, they just could not fail a PR.

The two jobs

android-library — ./gradlew :unity-plugin:assembleRelease, run inside the game-ci editor image.

I first wrote this as a plain ubuntu job on the premise that an Android library needs no Unity. That was wrong, and the first CI run said so: unity-plugin compiles against compileOnly files('libs/unity-classes.jar'), the jar is gitignored, and copyUnityClassesJar sources it from $UNITY_CLASSES_JAR or else a macOS Unity Hub path — the same shape as getUnityExePath() in the root build.gradle. On a bare Linux runner the Copy task finds nothing, no-ops silently, and Kotlin compilation fails on a missing classpath entry.

The job now runs in the editor image purely to obtain that jar, located with find rather than a hardcoded Variations/<backend>/Release/Classes path since that layout has moved between editor versions. No Unity process is launched, so it still consumes no license seat — unlike ci and tests. The image tag is pinned and checked against ProjectVersion.txt, same as release.yaml.

tests — game-ci/unity-test-runner@v4, testMode: EditMode because Tests.asmdef is Editor-only. unityVersion defaults to auto, which reads ProjectSettings/ProjectVersion.txt, so there is no editor version pinned here to drift.

Why tests has needs: ci

A Unity serial has a fixed seat count, and each Unity job holds one for its whole duration. The ci matrix already holds two concurrently — which is the most this repo has ever demonstrated working. Running tests in parallel would need a third simultaneous seat, and the failure mode is ugly: activation fails with an error that reads as a broken workflow rather than a capacity limit.

Sequencing keeps peak concurrency at two. The cost is wall-clock — tests waits for both player legs.

Note this does add one more activate/return cycle per PR run. Peak concurrency is unchanged, but it is one more round trip to Unity's licensing service, and one more place a hard-killed runner can leak a seat.

Swift is deliberately out of scope

Assets/Plugins/iOS/*.swift is still compiled by nothing, and the changes in #142 touch it. Two options, neither a config tweak:

• Full path — macOS runner, Unity installed via unity-hub on every run (no prebuilt macOS image), Xcode project generated, then xcodebuild. Roughly 30–45 minutes against ~5 for the Linux legs, plus SPM resolution, the post-build script and another license seat. Slow and fragile.
• SwiftPM type-check harness — a Package.swift depending on AirshipFrameworkProxy that includes the plugin's Swift sources with a stub for AirshipUnityCBridge. No Unity, no seat, a few minutes, and it gives real type checking. Needs the stub written and maintained, and it would not catch problems in the generated Xcode project or the post-build script.

A swiftc -parse syntax check is not worth adding: it would miss type errors, which is exactly where the risk in #142 sits, so a green result would be false confidence.

I'd suggest the harness as a follow-up ticket rather than blocking on it here.

Suggested order

Merge this before #142, so #142's next run compile-checks its Kotlin and runs its tests.

First-run risks

Neither job has run yet — no way to exercise a pull_request workflow without a PR.

• android-library may need compileSdk 36 downloaded inside the container. The image accepts SDK licences and makes the SDK dir writable, so AGP should handle it, but it's the most likely remaining wrinkle.
• unity-test-runner passes coverageOptions by default; if the code-coverage package isn't present Unity should ignore the arguments, but that's the second thing to look at.

🤖 Generated with Claude Code