Publish Kotlin Build Scans and cache to the OSS Community Develocity instance - #124
Conversation
…instance Replace the self-hosted HttpBuildCache with Develocity's remote cache at community.develocity.cloud under project `meshtastic`, matching the Meshtastic-Android onboarding (meshtastic/Meshtastic-Android#6531) and the rest of the org rollout. This covers the Kotlin binding only — the C, Swift, Python, C# and TypeScript bindings bring their own tooling and are untouched. kotlin/gradle/develocity.settings.gradle replaces kotlin/gradle/build-cache.settings.gradle. The cache now comes from Develocity, so scan and cache configuration are one concern in one file. The three workflows need two different wirings, because only ci.yml uses setup-gradle. Its two call sites take the key as an action input. release.yml and docs.yml invoke ./gradlew directly with no setup-gradle step, so there is no input to carry the key — they get DEVELOCITY_ACCESS_KEY as workflow env, which the Develocity plugin reads itself. docs.yml had no env block at all and needed one added. Without this those two workflows would have lost their GRADLE_CACHE_* credentials and gained nothing, leaving them with no remote cache. Scans publish only from authenticated builds, so fork PRs and developers who have not run `./gradlew provisionDevelocityAccessKey` publish nothing rather than failing. Only authenticated CI runs write to the cache, so unmerged and fork code cannot poison it. Scans record no machine identity: usernames, hostnames, IP addresses and external process names are obfuscated to constants. The GRADLE_CACHE_* secrets are no longer read but are deliberately left in place as the rollback path. Verified: spotlessCheck detekt apiCheck jvmTest, 44 tasks, scan published under root project name takpacket-sdk.
|
Warning Review limit reached
Next review available in: 38 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe project replaces self-hosted Gradle cache settings with Develocity configuration. Gradle workflows now use the Develocity access key. The README includes a Develocity build-scan badge. ChangesDevelocity migration
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/docs.yml:
- Around line 46-50: Scope Develocity authentication to Gradle execution rather
than the entire workflow: in .github/workflows/docs.yml at lines 46-50, remove
the workflow-level DEVELOCITY_ACCESS_KEY and pass it through
gradle/actions/setup-gradle using develocity-access-key or expose it only on the
Gradle step; apply the same change in .github/workflows/release.yml at lines
18-20, ensuring non-Gradle steps do not receive the secret.
In `@kotlin/gradle/develocity.settings.gradle`:
- Around line 51-55: Update the Develocity cache configuration around
remote(develocityBuildCache) so anonymous writes are denied through the
project’s Develocity ACLs, and restrict DEVELOCITY_ACCESS_KEY availability to
trusted CI events rather than treating any non-empty key as sufficient. Keep
push enabled only for trusted CI runs with the approved credential, while
preserving read access for other builds.
- Around line 17-37: Update the buildScan publishing gate in the buildScan
configuration so publication is limited to authenticated CI builds, preventing
developer-local scans even when a Develocity access key is configured. Preserve
the existing unauthenticated behavior and leave the obfuscation configuration
unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: d92e2f21-a216-49e2-9975-6a282debc2d3
📒 Files selected for processing (7)
.github/workflows/ci.yml.github/workflows/docs.yml.github/workflows/release.ymlREADME.mdkotlin/gradle/build-cache.settings.gradlekotlin/gradle/develocity.settings.gradlekotlin/settings.gradle.kts
💤 Files with no reviewable changes (1)
- kotlin/gradle/build-cache.settings.gradle
…radle steps
Two review findings from the Develocity onboarding, both worth fixing.
Cache writes were gated only on CI plus a non-empty DEVELOCITY_ACCESS_KEY.
Same-repository pull requests DO receive repository secrets, so a PR build could
write entries into the shared cache. The self-hosted HttpBuildCache this
replaced gated on GITHUB_EVENT_NAME and excluded pull_request; that protection
was lost in the port and is restored here. Verified against a CI-shaped
environment:
CI=true GITHUB_EVENT_NAME=pull_request -> pull-only
CI=true GITHUB_EVENT_NAME=push -> writes enabled
CI=true GITHUB_EVENT_NAME=merge_group -> writes enabled
Local builds are still excluded by isCI, and fork PRs have no key at all.
The access key was also declared at workflow level in docs.yml and release.yml,
which exposed it to every step in those jobs — including the Swift, Python,
TypeScript and C# steps that have no use for it. Move it to step-level env on
the five ./gradlew invocations instead, merging into the existing env blocks
where the step already had one rather than adding a second (a duplicate `env:`
key is invalid YAML). All workflow files re-validated with yq.
1 participant
Publishes Build Scans® and moves the remote build cache for the Kotlin
binding to the OSS Community Develocity instance at
https://community.develocity.cloud under project ID
meshtastic, matching theMeshtastic-Android onboarding (meshtastic/Meshtastic-Android#6531) and the rest
of the org rollout:
The C, Swift, Python, C# and TypeScript bindings bring their own tooling and are
untouched —
kotlin/is the only Gradle build, so it is the only partDevelocity can see.
What changed
kotlin/gradle/develocity.settings.gradlereplaceskotlin/gradle/build-cache.settings.gradle. The cache now comes fromDevelocity, so scan and cache configuration are one concern in one file.
HttpBuildCacheis replaced byremote(develocity.buildCache).Two different CI wirings, because only
ci.ymlusessetup-gradlesetup-gradle?ci.ymldevelocity-access-keyaction inputrelease.ymlDEVELOCITY_ACCESS_KEYworkflowenvdocs.ymlDEVELOCITY_ACCESS_KEYworkflowenv(block added)release.ymlanddocs.ymlinvoke./gradlewdirectly, so there is no actioninput to carry the key — they read the environment variable the Develocity
plugin looks up itself. This matters: without it, those two workflows would have
lost their
GRADLE_CACHE_*credentials and gained nothing, ending up with noremote cache at all.
Behaviour
publishing.onlyIf { it.authenticated }).Fork PRs and developers who have not run
./gradlew provisionDevelocityAccessKeypublish nothing rather than failing.cannot poison it. CI disables the local cache — runners are ephemeral and
every hit comes from the remote anyway.
external process names are obfuscated to constants.
Verification
cd kotlin && ./gradlew spotlessCheck detekt apiCheck jvmTest --stacktrace—BUILD SUCCESSFUL, 44 tasks, scan published under root project name
takpacket-sdk.On the kzstd pilot this same configuration measured a 59% build-time
avoidance ratio on the second CI run, entirely from remote cache hits.
Note:
jvmTestregeneratestestdata/compression-report.mdas a side effect.Only its
Generated:date line changed — no compression differences — so it isdeliberately excluded from this PR.
Note for reviewers
The
GRADLE_CACHE_*repository secrets are now unused but deliberately notdeleted — they are the rollback path.
Summary by CodeRabbit
Build & Release
Documentation