v3.8.1

What's Changed

Gradle builds no longer get an auth token in the init script

• The plugins resolve their own token (#517). remote-cache 2.1.0 and gradle-analytics 3.2.3 run bitrise-build-cache auth token themselves, so activate gradle stops writing authToken for the cache and analytics plugins. test-distribution still takes its token from the init script.

  This is what lets the configuration cache work with a rotating per-build JWT. A configured token is a configuration-cache input, so an entry saved with one was pinned to it and a per-build token invalidated the entry on every build; the plugins now keep resolution off that path. Leaving a token in the init script would have kept the old behaviour, because a configured token overrides the CLI — so the removal ships with the version bump rather than after it.

• activate gradle exports BITRISE_BUILD_CACHE_CLI. The plugins look for the CLI in that variable, on $PATH and in ~/.bitrise/bin, while the Gradle step installs it into /tmp/bin — none of the three. The export closes that gap through envman on Bitrise and GITHUB_ENV on GitHub Actions.

• Plugin versions: common 1.0.8, remote-cache 2.1.0, gradle-analytics 3.2.3, test-distribution 2.2.11.

Upgrading

No action needed. Gradle builds authenticate exactly as before; builds using the configuration cache no longer need a long-lived PAT or workspace token to keep their entry valid.

Changelog

• d5a639e Merge pull request #517 from bitrise-io/update-plugins

Gradle verification

For reference, the verification metadata is available as an attached assset.