Skip to content

Onboard to the OSS Community Develocity Instance - #6531

Merged
jamesarich merged 1 commit into
meshtastic:mainfrom
clayburn:dv/onboard-oss-community-develocity-instance
Jul 31, 2026
Merged

Onboard to the OSS Community Develocity Instance#6531
jamesarich merged 1 commit into
meshtastic:mainfrom
clayburn:dv/onboard-oss-community-develocity-instance

Conversation

@clayburn

@clayburn clayburn commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

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

  • The Develocity Gradle extension/plugin and the Common Custom User Data Gradle
    extension/plugin, applied at the latest released versions.
  • settings.gradle.kts pointing the build at https://community.develocity.cloud and
    associating builds with project meshtastic.
  • A "Revved up by Develocity" badge in the README linking to the filtered Build Scan list
    for this project's root project name.
  • A setup step in each GitHub Actions workflow that runs the build, so CI publishes Build
    Scans automatically using a short-lived access token.

Changes to configuration that already existed

This project already applied com.gradle.develocity 4.5.0, so this PR adapts the existing
setup rather than adding it from scratch. Please review these three points.

  1. Build Scans move from scans.gradle.com to community.develocity.cloud. The
    termsOfUseUrl and termsOfUseAgree settings are removed, because they apply only to
    the public scans.gradle.com service. Publishing now happens whenever the build is
    authenticated, instead of on CI only, so local builds also publish once a developer
    provisions a key (see Step 3). The explicit capture { fileFingerprints = true } is
    dropped in favor of the plugin default.
  2. The remote Build Cache moves to Develocity. gradle/build-cache.settings.gradle
    keeps its role as the single place cache configuration lives, but its self-hosted
    HttpBuildCache is replaced by remote(develocity.buildCache). The now-unused
    GRADLE_CACHE_URL, GRADLE_CACHE_USERNAME, and GRADLE_CACHE_PASSWORD plumbing is
    removed from the workflows; GRADLE_CACHE_READ_ONLY stays, because it controls the
    Actions-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.
  3. The access key is wired through the shared composite action.
    .github/actions/gradle-setup gets a new optional develocity_access_key input that it
    forwards to gradle/actions/setup-gradle. All 14 call sites pass
    secrets.DEVELOCITY_ACCESS_KEY, and verify-flatpak.yml (which calls setup-gradle
    directly) passes it too. Every input is optional, so builds without the secret keep
    working.

Step 1 — Get an access key for community.develocity.cloud

Build Scan publishing and Build Cache writes from CI need a Develocity access key.

  1. Visit https://community.develocity.cloud.
  2. Sign in as the CI service account that the Develocity Solutions team has provisioned
    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.
  3. From the user menu in the top-right, open My settingsAccess keys.
  4. Click Generate access key, give it a description (e.g. GitHub Actions), and copy
    the 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_KEY to authenticate to
community.develocity.cloud.

  1. Open this repository on GitHub.

  2. Click Settings.

  3. In the left sidebar, click Secrets and variablesActions.

  4. Click New repository secret. (If a DEVELOCITY_ACCESS_KEY secret already exists,
    click its Update button instead.)

  5. Set Name to:

    DEVELOCITY_ACCESS_KEY
    
  6. Set Secret to the value below, replacing PASTE_THE_ACCESS_KEY_FROM_STEP_1_HERE
    with the key you copied in Step 1:

    community.develocity.cloud=PASTE_THE_ACCESS_KEY_FROM_STEP_1_HERE
    

    The community.develocity.cloud= prefix is required — without the host name, the
    access key is silently ignored. This is the most common point of failure when
    onboarding, so please double-check the format.

  7. 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.cloud so their Build Scans publish and they get reads
from the remote Build Cache. The Develocity Gradle plugin's
provisionDevelocityAccessKey task does this in a single command — it opens
the browser, asks the developer to confirm, and writes the key to
~/.gradle/develocity/keys.properties automatically.

Before running this command, sign out of community.develocity.cloud in
your 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.

./gradlew provisionDevelocityAccessKey

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.cloud even after you set
the secret in Step 2.

If you want CI verification before merging, push the branch
dv/onboard-oss-community-develocity-instance to a temporary branch on this repo (not
the 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

    • Improved build performance and reliability through streamlined remote caching.
    • Enhanced build scan availability and privacy controls for diagnostics.
    • Updated automated documentation, release, and verification workflows for more consistent builds.
  • Documentation

    • Added a Develocity status badge to the README, providing direct access to build scan information.

@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

1 similar comment
@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@coderabbitai

coderabbitai Bot commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

Gradle 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.

Changes

Develocity integration

Layer / File(s) Summary
Gradle Develocity configuration
settings.gradle.kts, gradle/build-cache.settings.gradle, README.md
Gradle configures Develocity scans and remote caching with CI-aware authentication. The README includes a Develocity badge.
Gradle setup action contract
.github/actions/gradle-setup/action.yml
The shared action accepts an optional develocity_access_key input and passes it to gradle/actions/setup-gradle.
Workflow secret propagation
.github/workflows/*.yml
Release, check, documentation, scheduled, and Flatpak workflows pass DEVELOCITY_ACCESS_KEY. Legacy Gradle cache secrets and environment exports were removed.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Possibly related PRs

Suggested labels: ci, build

Suggested reviewers: jamesarich, vidplace7

🚥 Pre-merge checks | ✅ 6
✅ Passed checks (6 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and concisely describes the main change: onboarding the project to the OSS Community Develocity Instance.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Sibling Call Sites And Presence Semantics ✅ Passed The PR changes only Gradle, workflow, README, and settings files; it adds no application field, zero-default, nullable field, or presence check requiring sibling call-site updates.
Tests Prove The Path, Not The End State ✅ Passed The pull request changes only Gradle and workflow configuration plus README content; no added or changed tests require assessment.

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added the repo Repository maintenance label Jul 31, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between fe38339 and ec6c539.

📒 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.yml
  • README.md
  • gradle/build-cache.settings.gradle
  • settings.gradle.kts

Comment thread gradle/build-cache.settings.gradle
Comment thread README.md
[![CLA assistant](https://cla-assistant.io/readme/badge/meshtastic/Meshtastic-Android)](https://cla-assistant.io/meshtastic/Meshtastic-Android)
[![Fiscal Contributors](https://opencollective.com/meshtastic/tiers/badge.svg?label=Fiscal%20Contributors&color=deeppink)](https://opencollective.com/meshtastic/)
[![Vercel](https://img.shields.io/static/v1?label=Powered%20by&message=Vercel&style=flat&logo=vercel&color=000000)](https://vercel.com?utm_source=meshtastic&utm_campaign=oss)
[![Revved up by Develocity](https://img.shields.io/badge/Revved%20up%20by-Develocity-06A0CE?logo=Gradle&labelColor=02303A)](https://community.develocity.cloud/scans?search.rootProjectNames=MeshtasticAndroid)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@jamesarich
jamesarich merged commit 06c5a95 into meshtastic:main Jul 31, 2026
17 of 18 checks passed
jamesarich added a commit to meshtastic/kzstd that referenced this pull request Aug 2, 2026
…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>
jamesarich added a commit to meshtastic/gradle-flatpak-sources that referenced this pull request Aug 3, 2026
…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.
github-merge-queue Bot pushed a commit to meshtastic/TAKPacket-SDK that referenced this pull request Aug 3, 2026
…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.
jamesarich added a commit that referenced this pull request Aug 3, 2026
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

repo Repository maintenance

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants