Gradle configuration cache now works with per-build JWT authentication

Description

Bitrise Build Cache no longer requires a long-lived PAT or workspace token for Gradle configuration cache reuse.

Highlights:

  • No long-lived token required: The Build Cache and Gradle Analytics plugins now resolve their own auth token by running bitrise-build-cache auth token, instead of receiving it directly as a configuration input.
  • Better configuration cache reuse: Because the auth token is no longer a configuration-cache input, configuration cache entries can now stay valid across builds that authenticate with different per-build JWTs, including on different machines.
  • No behavior change for explicit tokens: If you explicitly set authToken on the plugin extensions, that still takes precedence and keeps the current behavior.
  • No action required: Builds continue to authenticate as before after upgrade.
  • Reproducible plugin artifacts: Published Gradle plugin JARs are now reproducible and byte-identical across machines, which is required for cross-machine configuration cache reuse.
  • CLI path exported automatically: The Gradle activation step now exports BITRISE_BUILD_CACHE_CLI so the plugins can locate the CLI installed by the Step.

Scope

This change applies to:

  • Build Cache
  • Gradle Analytics

Note: test-distribution was not migrated to this token resolution flow and still receives its token through the generated init script.

Versions

  • io.bitrise.gradle:common 1.0.8
  • io.bitrise.gradle:remote-cache 2.1.0
  • io.bitrise.gradle:gradle-analytics 3.2.3
  • io.bitrise.gradle:test-distribution 2.2.11
  • bitrise-build-cache-cli v3.8.1
  • activate-build-cache-for-gradle 3.6.1
  • activate-build-cache-for-xcode 0.22.1
  • activate-build-cache-for-react-native 0.16.1

Why This Matters

Per-build JWTs are more secure and easier to manage than long-lived tokens, but they previously got in the way of Gradle configuration cache reuse because each new token changed the cache input set. With this update, teams can keep using per-build authentication without invalidating configuration cache entries on every build.

Bottom line: Gradle configuration cache entries can now be reused across builds authenticated with different per-build JWTs, with no workflow changes required.