ci: cache API compatibility production compilation

[jbeckwith-oai]

Summary

• keep the Gradle build cache enabled for ordinary production compilation in the API compatibility job
• explicitly make the external and proposed compatibility compilation tasks non-cacheable and never up-to-date, so both still execute on every detector pass
• add a regression test that guards the cache-safety boundary

Why

The API compatibility job is frequently on the required-CI critical path. Its global --no-build-cache flag forced the large production Kotlin compilation to rerun even when an identical content-addressed result was available. Compatibility fixtures still need fresh compilation, but that does not require disabling caching for the entire build.

Local measurement

With relevant module outputs removed before each run on the same commit:

• cache population run: 3m30s
• cache restoration run: 1m05s
• local improvement: 2m25s

The restoration run reported both production Kotlin compilations FROM-CACHE, while compileExternalApiCompatibilityKotlin and compileProposedApiCompatibilityKotlin both executed normally.

CI experiment result

The first PR run completed the API compatibility job in 10m54s, effectively unchanged from the 10–11 minute baseline. Although setup-gradle restored a default-branch cache, all 16 Gradle tasks executed and openai-java-core:compileKotlin took about 6m24s. The restored entry came from the default-branch analyze job, where CodeQL intentionally runs with --no-build-cache, so it did not contain a matching production compilation result.

This draft therefore does not yet meet the performance acceptance bar. It remains open to discuss whether explicit trusted cache seeding is worth its additional CI cost and cache-poisoning boundary; no review is requested yet.

Safety validation

• both compatibility compilation tasks are explicitly non-cacheable
• both tasks are forced out of Gradle's up-to-date shortcut
• both baseline and proposed public API signature checks pass on a compatible change
• a temporary nonexistent public API signature was correctly rejected, confirming the detector still fails closed

Validation

• bash -n scripts/detect-breaking-changes
• ./scripts/gradle :buildSrc:test
• ./scripts/lint
• ./scripts/test
• full API compatibility detector, cold-output and warm-cache passes
• all GitHub checks green, including both CodeQL workflows

[Copilot]

Pull request overview

This PR optimizes the API compatibility CI job by re-enabling Gradle build cache for normal production compilation while ensuring the API compatibility fixture compilations still always execute (never up-to-date and never cacheable). This reduces required-CI wall time without weakening the “fail closed” behavior of the compatibility detector.

Changes:

• Remove the global --no-build-cache from the API compatibility detector Gradle invocation.
• Add an init-script policy to force the compatibility compilation tasks to always run and to never use the build cache.
• Add a buildSrc regression test (with proper task inputs) to guard this cache-safety boundary.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
scripts/detect-breaking-changes	Keeps build cache enabled for production compilation, while forcing compatibility compilation tasks to be non-cacheable and never up-to-date.
buildSrc/src/test/kotlin/com/openai/gradle/ApiCompatibilityCachePolicyTest.kt	Adds a regression test to ensure the detector script retains the intended caching policy.
buildSrc/build.gradle.kts	Configures the buildSrc test task to track the detector script as an input so changes invalidate test up-to-date checks.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.