ci: onboard to the OSS Community Develocity instance - #36
Conversation
|
Warning Review limit reached
Next review available in: 55 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 (7)
📝 WalkthroughWalkthroughThe build now uses Gradle Develocity for build scans and remote caching. CI workflows provide the Develocity access key. The README includes a Develocity badge. ChangesDevelocity integration
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant CI Workflow
participant Gradle
participant Develocity
CI Workflow->>Gradle: Provide DEVELOCITY_ACCESS_KEY
Gradle->>Develocity: Publish build scan when authenticated
Gradle->>Develocity: Read or write remote build cache
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1⚔️ Resolve merge conflicts 💡
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 |
…tance Replaces 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). Scans publish only from authenticated builds, so fork PRs and developers who have not provisioned a key are unaffected; only authenticated CI runs write to the cache. The GRADLE_CACHE_URL / _USERNAME / _PASSWORD secrets are no longer read, but are deliberately left in place as the rollback path. Signed-off-by: James Rich <james.a.rich@gmail.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@gradle/develocity.settings.gradle`:
- Around line 39-54: Update the remote cache configuration in buildCache so its
enabled state requires a valid trimmed accessKey in addition to the existing
access conditions. Keep push restricted to authenticated CI as currently
implemented, and preserve the local cache behavior.
In `@settings.gradle.kts`:
- Around line 9-14: Update the com.gradle.common-custom-user-data-gradle-plugin
declaration in the plugins block to use an available published release, keeping
the existing Develocity plugin 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: 0daea208-6ec8-400a-ad29-8bc634cd612e
📒 Files selected for processing (7)
.github/workflows/ci.yml.github/workflows/docs.yml.github/workflows/release.ymlREADME.mdgradle/build-cache.settings.gradlegradle/develocity.settings.gradlesettings.gradle.kts
💤 Files with no reviewable changes (1)
- gradle/build-cache.settings.gradle
2fbd0cd to
1e744de
Compare
…tance Replaces 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 kzstd pilot (meshtastic/kzstd#36). Scans publish only from authenticated builds, so fork PRs and developers who have not provisioned a key are unaffected; only authenticated CI runs write to the cache. The GRADLE_CACHE_URL / _USERNAME / _PASSWORD secrets are no longer read, but are deliberately left in place as the rollback path.
Remote cache writes were gated on CI plus a non-empty DEVELOCITY_ACCESS_KEY.
A same-repository pull request DOES receive repository secrets, so PR builds
were writing entries into the shared cache — unmerged code could serve results
to main.
Require GITHUB_EVENT_NAME to be push or merge_group as well. Cache population is
unaffected: main-check.yml (push to main) and merge-queue.yml (merge_group) are
both still trusted writers, and they are the runs whose outputs correspond to
code that actually landed. pull-request.yml becomes pull-only, which is what it
should have been.
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
Fork PRs have no key and are excluded twice over; local builds are excluded by
isCI.
This restores the protection the self-hosted HttpBuildCache had before #6531 —
it gated on GITHUB_EVENT_NAME and excluded pull_request. The same gap was found
and fixed across the six repos being onboarded now (meshtastic/kzstd#36 and
siblings); this brings android back in line.
1 participant
Publishes Build Scans® and moves the remote build cache to the OSS Community
Develocity instance at https://community.develocity.cloud under project ID
meshtastic, matching the Meshtastic-Android onboarding(meshtastic/Meshtastic-Android#6531). This is the pilot for rolling the same
configuration out to the rest of the Meshtastic Gradle repos.
What changed
gradle/develocity.settings.gradlereplacesgradle/build-cache.settings.gradle.The cache now comes from Develocity, so scan and cache configuration are one
concern in one file. Applying
com.gradle.develocityand the Common CustomUser Data plugin happens in
settings.gradle.kts; everything else lives inthe applied script.
HttpBuildCacheis replaced byremote(develocity.buildCache).setup-gradlecall sites (ci.yml×2,release.yml,docs.yml)gain an optional
develocity-access-key. TheGRADLE_CACHE_URL/GRADLE_CACHE_USERNAME/GRADLE_CACHE_PASSWORDenv block is removed fromci.yml.Behaviour
publishing.onlyIf { it.authenticated }).Fork PRs and developers who have not provisioned a key are unaffected — they
publish nothing rather than failing.
cannot poison it. Local builds read remotely and use a local cache; CI
disables the local cache, since runners are ephemeral and every hit comes
from the remote anyway.
external process names are obfuscated to constants.
Local verification
--configuration-cachetwice).meshtasticwith root project namekzstd.jvmTestwent 33s → 3s with 3 tasksFROM-CACHE../gradlew spotlessCheck detekt apiCheck jvmTestis green.apiCheckpasseswithout an
apiDump, confirming this settings-only change does not move theABI.
Notes for reviewers
GRADLE_CACHE_*repository secrets are now unused but are deliberatelynot deleted — they are the rollback path if the community instance turns out
not to suit us.
./gradlew provisionDevelocityAccessKeyonce.Summary by CodeRabbit
Build & Performance
Documentation