Repository navigation
build: onboard to ASF Develocity (develocity.apache.org) for build scans #257
Description
Status: PR #258 by @adityamparikh is open and covers steps 2 to 4 of the issue (build, CI, docs). For step 1, the PR body says Infra enabled the DEVELOCITY_ACCESS_KEY secret for this repo in INFRA-28504. Unverified: the ticket needs a Jira login and repo secrets aren't listable without write access. The PR's fork CI runs are action_required.
Size: S — the code is written. What remains is a CI approval, a review and a merge.
What PR #258 does
settings.gradle.ktsappliescom.gradle.develocity4.6.0 andcom.gradle.common-custom-user-data-gradle-plugin2.8.0.- It sets
server = "https://develocity.apache.org"andprojectId = "solr-mcp". - Scans publish only on CI, or locally with
-Pscan, and only with an authenticated key. - IP addresses are obfuscated. Scans are tagged with the JDK,
PRand the workflow name.
- It sets
ci.yml,build-and-publish.ymlandnative.ymlexportDEVELOCITY_ACCESS_KEYfromsecrets.DEVELOCITY_ACCESS_KEYat workflow level. A composite action can't read secrets, so this can't live in.github/actions/setup-javaas the issue suggested.dev-docs/DEVELOPMENT.mdgets a Build Scans section with the scan list and the 90-day test-history links.
Fork PRs receive no secrets, so #258's own runs publish nothing. The first scan comes from build-and-publish.yml on main after the merge.
What remains
- A committer approves the fork CI run on build: publish Gradle build scans to develocity.apache.org #258's head, then reviews and merges it.
- The first
mainbuild after the merge shows up athttps://develocity.apache.org/scans?search.rootProjectNames=solr-mcp, tagged with the JDK and workflow name. If none appears, check the secret name with Infra: a misnamed secret resolves to an empty string and the build publishes nothing, without an error. - Close build: onboard to ASF Develocity (develocity.apache.org) for build scans #257.
Out of scope
The remote build cache. It needs a separate write-scoped CI user and key from Infra (issue section "Follow-up"). Open a new issue for it once scans are live.
File and line references are against main at 7cb39a3d.
Original description
What
Publish Gradle build scans from solr-mcp's CI to the ASF Develocity instance at
develocity.apache.org, the way apache/solr already does.
Why
- CI failures are hard to diagnose today. Fork PRs need committer approval before CI runs, and
the only evidence of a failure is the raw log. A build scan gives a shareable page with task
timings, the full test report, failures, dependency resolution and the environment. - Flaky tests become visible. The Testcontainers integration tests and the Solr compatibility
matrix (-Dsolr.test.image=...) fail intermittently. Develocity's test history aggregates results
across runs, so a flake shows up as a pattern instead of a one-off red build. Solr links its
history fromdev-docs/FAQ.adoc:
https://develocity.apache.org/scans/tests?search.rootProjectNames=solr*. - No new infrastructure. The ASF runs the instance for its projects at no cost.
Proposed change
- Infra access. Ask Infra (a PMC member files the INFRA Jira ticket, per
infra.apache.org/gradle.html and the
onboarding instructions)
to onboardapache/solr-mcpand confirm which Actions secret carries the access key. Some
projects use the sharedDEVELOCITY_ACCESS_KEY(e.g. Publish build scans to develocity.apache.org and update Develocity plugins samza#1723); apache/solr uses a
project-scopedSOLR_DEVELOCITY_ACCESS_KEY. - Build. In
settings.gradle.kts, applycom.gradle.develocityand
com.gradle.common-custom-user-data-gradle-plugin, and configure:server = "https://develocity.apache.org"andprojectId = "solr-mcp", so scans are
attributed to this project on the shared instance.publishing.onlyIf { it.authenticated }on CI. Fork PRs receive no secrets, so they don't
publish and the build is unaffected. Locally, publish only when opted in with-Pscan.- IP-address obfuscation and tags for the JDK version,
PRand the workflow name, matching
Solr'sgradle/develocity.gradle.
- CI. Export the access key as
DEVELOCITY_ACCESS_KEYin theci.yml,
build-and-publish.ymlandnative.ymljobs that run./gradlew. Do this in the shared
.github/actions/setup-javacomposite action where possible, so it lives in one place. - Docs. Add the test-history link for
solr-mcptodev-docs.
Follow-up: remote build cache
The remote build cache is onboarded separately: Infra creates a dedicated CI user and a write-scoped
key. Without one, writes return 403 (apache/grails-core#16346, INFRA-27642 / INFRA-28501). Once
build scans are live, we can request that key so that CI on main writes to the cache and PRs and
laptops read from it.
Activity
adityamparikh commentedon Oct 12, 2026
Infra onboarding (step 1) is tracked in INFRA-28504. The build and CI changes are in #258.
build: publish Gradle build scans to develocity.apache.org