adityamparikh opened a new issue, #257:
URL: https://github.com/apache/solr-mcp/issues/257

   ### What
   
   Publish Gradle build scans from solr-mcp's CI to the ASF Develocity instance 
at
   [develocity.apache.org](https://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 from `dev-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
   
   1. **Infra access.** Ask Infra (a PMC member files the INFRA Jira ticket, per
      [infra.apache.org/gradle.html](https://infra.apache.org/gradle.html) and 
the
      [onboarding 
instructions](https://cwiki.apache.org/confluence/display/INFRA/Project+Onboarding+Instructions+for+Develocity))
      to onboard `apache/solr-mcp` and confirm which Actions secret carries the 
access key. Some
      projects use the shared `DEVELOCITY_ACCESS_KEY` (e.g. apache/samza#1723); 
apache/solr uses a
      project-scoped `SOLR_DEVELOCITY_ACCESS_KEY`.
   2. **Build.** In `settings.gradle.kts`, apply `com.gradle.develocity` and
      `com.gradle.common-custom-user-data-gradle-plugin`, and configure:
      - `server = "https://develocity.apache.org"` and `projectId = 
"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, `PR` and the 
workflow name, matching
        Solr's 
[`gradle/develocity.gradle`](https://github.com/apache/solr/blob/main/gradle/develocity.gradle).
   3. **CI.** Export the access key as `DEVELOCITY_ACCESS_KEY` in the `ci.yml`,
      `build-and-publish.yml` and `native.yml` jobs that run `./gradlew`. Do 
this in the shared
      `.github/actions/setup-java` composite action where possible, so it lives 
in one place.
   4. **Docs.** Add the test-history link for `solr-mcp` to `dev-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.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to