Onboard to the OSS Community Develocity Instance - #6531
Conversation
|
|
1 similar comment
|
|
📝 WalkthroughWalkthroughGradle now uses Develocity for build scans and remote caching. The shared Gradle setup action accepts an access key, and CI workflows pass the repository secret while removing legacy cache credentials. A Develocity badge was added to the README. ChangesDevelocity integration
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 6✅ Passed checks (6 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: 1
🤖 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/build-cache.settings.gradle`:
- Around line 18-32: Update the push assignment inside the remote build cache
configuration to require a trusted CI ref or event, such as main-branch or
merge-queue runs, in addition to CI being set and DEVELOCITY_ACCESS_KEY being
present. Ensure feature-branch and pull-request runs cannot push to the shared
cache, while preserving remote caching and existing local-cache behavior.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 72ef5a1c-e326-4c60-b4b2-95aebce399a6
📒 Files selected for processing (10)
.github/actions/gradle-setup/action.yml.github/workflows/docs-deploy.yml.github/workflows/docs-release.yml.github/workflows/release.yml.github/workflows/reusable-check.yml.github/workflows/scheduled-baseline.yml.github/workflows/verify-flatpak.ymlREADME.mdgradle/build-cache.settings.gradlesettings.gradle.kts
| [](https://cla-assistant.io/meshtastic/Meshtastic-Android) | ||
| [](https://opencollective.com/meshtastic/) | ||
| [](https://vercel.com?utm_source=meshtastic&utm_campaign=oss) | ||
| [](https://community.develocity.cloud/scans?search.rootProjectNames=MeshtasticAndroid) |
…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>
…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.
…instance (#124) * Publish Kotlin Build Scans and cache to the OSS Community Develocity 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. * Restrict cache writes to trusted events and scope the access key to Gradle 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.
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.
Onboard to the OSS Community Develocity Instance
This PR adds Develocity Build Scan® and Build Cache support
for this project, publishing to the OSS Community Develocity Instance at
https://community.develocity.cloud under project ID
meshtastic.What this PR adds
extension/plugin, applied at the latest released versions.
https://community.develocity.cloudandassociating builds with project
meshtastic.for this project's root project name.
Scans automatically using a short-lived access token.
Changes to configuration that already existed
This project already applied
com.gradle.develocity4.5.0, so this PR adapts the existingsetup rather than adding it from scratch. Please review these three points.
scans.gradle.comtocommunity.develocity.cloud. ThetermsOfUseUrlandtermsOfUseAgreesettings are removed, because they apply only tothe public
scans.gradle.comservice. Publishing now happens whenever the build isauthenticated, instead of on CI only, so local builds also publish once a developer
provisions a key (see Step 3). The explicit
capture { fileFingerprints = true }isdropped in favor of the plugin default.
gradle/build-cache.settings.gradlekeeps its role as the single place cache configuration lives, but its self-hosted
HttpBuildCacheis replaced byremote(develocity.buildCache). The now-unusedGRADLE_CACHE_URL,GRADLE_CACHE_USERNAME, andGRADLE_CACHE_PASSWORDplumbing isremoved from the workflows;
GRADLE_CACHE_READ_ONLYstays, because it controls theActions-side Gradle home cache, not the remote cache. Pushes to the cache happen only
from CI runs that have the access key, so pull requests from forks read without
writing.
.github/actions/gradle-setupgets a new optionaldevelocity_access_keyinput that itforwards to
gradle/actions/setup-gradle. All 14 call sites passsecrets.DEVELOCITY_ACCESS_KEY, andverify-flatpak.yml(which callssetup-gradledirectly) passes it too. Every input is optional, so builds without the secret keep
working.
Step 1 — Get an access key for
community.develocity.cloudBuild Scan publishing and Build Cache writes from CI need a Develocity access key.
for your project — that account was shared with you out-of-band when this onboarding
was set up. The access key inherits that account's project memberships and permissions,
which is exactly what you want for CI.
GitHub Actions), and copythe generated key. Keep this tab open until you complete Step 2 — the key is only
shown once.
Step 2 — Set the GitHub Actions secret on this repository
CI uses a repository secret named
DEVELOCITY_ACCESS_KEYto authenticate tocommunity.develocity.cloud.Open this repository on GitHub.
Click Settings.
In the left sidebar, click Secrets and variables → Actions.
Click New repository secret. (If a
DEVELOCITY_ACCESS_KEYsecret already exists,click its Update button instead.)
Set Name to:
Set Secret to the value below, replacing
PASTE_THE_ACCESS_KEY_FROM_STEP_1_HEREwith the key you copied in Step 1:
The
community.develocity.cloud=prefix is required — without the host name, theaccess key is silently ignored. This is the most common point of failure when
onboarding, so please double-check the format.
Click Add secret (or Update secret).
Step 3 — Provision an access key for your local builds
Developers building this project locally should provision an access key for
community.develocity.cloudso their Build Scans publish and they get readsfrom the remote Build Cache. The Develocity Gradle plugin's
provisionDevelocityAccessKeytask does this in a single command — it opensthe browser, asks the developer to confirm, and writes the key to
~/.gradle/develocity/keys.propertiesautomatically.Before running this command, sign out of
community.develocity.cloudinyour browser (or use a private/incognito window) so the access key gets
associated with your personal account, not the CI service account you
signed in as for Step 1.
Note on the CI run on this PR
This PR was prepared from a fork. Forks can't read your repository's secrets, so the
workflow run on this PR cannot publish to
community.develocity.cloudeven after you setthe secret in Step 2.
If you want CI verification before merging, push the branch
dv/onboard-oss-community-develocity-instanceto a temporary branch on this repo (notthe fork) and re-run the workflow there — it will pick up the secret and publish a Build
Scan.
After merging, every CI run on this repository will publish a Build Scan to
https://community.develocity.cloud. CI runs from forks of this repository will not (forks
don't have access to the secret either), and that's expected.
Summary by CodeRabbit
Improvements
Documentation