ci: move Build Scans and cache to the OSS Community Develocity instance - #91
Conversation
This project already applied com.gradle.develocity, but pointed at the default scans.gradle.com and kept a separate self-hosted HttpBuildCache. Both now move to community.develocity.cloud under project `meshtastic`, matching the Meshtastic-Android onboarding (meshtastic/Meshtastic-Android#6531). - `gradle/develocity.settings.gradle` gains `server` + `projectId`, and absorbs the build cache from `gradle/build-cache.settings.gradle`, which is deleted. Both settings files now apply one script instead of two. - `termsOfUseUrl` / `termsOfUseAgree` are dropped: they apply only to the public scans.gradle.com service. - Scan publishing is gated on authentication rather than on CI, so local builds publish too once a developer runs `./gradlew provisionDevelocityAccessKey`. Fork PRs and unprovisioned developers publish nothing rather than failing. - Scans are obfuscated: no username, hostname, IP or external process name. - CCUD 2.7.0 -> 2.8.0. - `.github/actions/gradle-setup` gains an optional `develocity_access_key` input, passed at all 9 composite call sites; docs.yml's direct setup-gradle gets it too. The GRADLE_CACHE_* env blocks are removed. The GRADLE_CACHE_* 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>
|
Warning Review limit reached
Next review available in: 2 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 (1)
📝 WalkthroughWalkthroughGradle cache and Build Scan configuration is consolidated under Develocity. The Gradle setup action accepts an optional access key. CI, documentation, and release workflows pass the repository secret to Gradle. ChangesDevelocity integration
Estimated code review effort: 3 (Moderate) | ~20 minutes 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 |
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 62-65: Update the remote cache configuration in
develocityBuildCache so push requires an explicit trusted-writer flag supplied
only by protected-branch jobs, in addition to CI and a non-empty access key. Do
not use the GitHub Actions cache_read_only setting or access-key presence alone
to authorize writes; preserve remote cache reads for other builds.
In `@README.md`:
- Line 11: Remove the Develocity badge from the README’s badge section, leaving
the remaining README content unchanged. Do not add a replacement badge or modify
the README for unrelated documentation; move project-status badges elsewhere
only if needed.
🪄 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: 475c9091-02e7-450c-b1af-7cf12855b463
📒 Files selected for processing (9)
.github/actions/gradle-setup/action.yml.github/workflows/ci.yml.github/workflows/docs.yml.github/workflows/release.ymlREADME.mdbuild-logic/settings.gradle.ktsgradle/build-cache.settings.gradlegradle/develocity.settings.gradlesettings.gradle.kts
💤 Files with no reviewable changes (1)
- gradle/build-cache.settings.gradle
Same-repository pull requests DO receive repository secrets, so gating cache
writes on the presence of DEVELOCITY_ACCESS_KEY alone let a PR build 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 real 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.
Signed-off-by: James Rich <james.a.rich@gmail.com>
This project already applied
com.gradle.develocity, but pointed at the defaultscans.gradle.comand kept a separate self-hostedHttpBuildCache. Both nowmove to the OSS Community Develocity instance at
https://community.develocity.cloud under project ID
meshtastic, matchingthe Meshtastic-Android onboarding (meshtastic/Meshtastic-Android#6531) and the
rest of the org rollout (meshtastic/kzstd#36,
meshtastic/gradle-flatpak-sources#28, meshtastic/MQTTastic-Client-KMP#118).
What changed
gradle/develocity.settings.gradlegainsserverandprojectId, andabsorbs the build cache from
gradle/build-cache.settings.gradle, which isdeleted. Both settings files now apply one script instead of two.
termsOfUseUrl/termsOfUseAgreeare dropped — they apply only to thepublic
scans.gradle.comservice. (Tested: the plugin does not reject themalongside a configured
server, so this is cleanliness, not a requirement.)builds publish too once a developer runs
./gradlew provisionDevelocityAccessKey. Fork PRs and unprovisioneddevelopers publish nothing rather than failing.
process name is recorded.
.github/actions/gradle-setupgains an optionaldevelocity_access_keyinput forwarded to
setup-gradle; all 9 composite call sites passsecrets.DEVELOCITY_ACCESS_KEY, as does the directsetup-gradleindocs.yml. TheGRADLE_CACHE_*env blocks are removed.Per
GOVERNANCE.mdthis is a day-to-day change (no public API, wire protocolor module-boundary impact), so it needs one maintainer approval and a green
./gradlew checkrather than an ADR.Verification
community.develocity.cloud— notscans.gradle.com—for both the root build (
meshtastic-sdk) and the included build(
build-logic, verified with./gradlew -p build-logic help)../gradlew checkgreen: 294 tasks. See the caveat below.Caveat:
spotlessMisccannot run in a Nix/direnv checkout./gradlew checkfails locally atspotlessMiscwithbecause the
miscformat target walks.direnv/flake-inputs/, which containsread-only Nix store paths (and, in a checkout with git worktrees, descends into
.claude/worktrees/too). This reproduces on a cleanmain, so it is notcaused by this PR, and CI runners have neither directory. The 294-task figure
above excludes
spotlessMisc/spotlessMiscCheck; everything else passes.A one-line exclusion in the spotless
misctarget would fix local runs — wortha separate PR.
Note for reviewers
The
GRADLE_CACHE_*repository secrets are now unused but deliberately notdeleted — they are the rollback path.
Summary by CodeRabbit