fix(manifest): detect Gradle projects by build script, not gradlew wrapper (REA-622)

[Jeppe Fredsgaard Blaabjerg (jfblaa)]

Problem

scan create . --auto-manifest (and socket manifest auto) skipped Gradle projects unless a gradlew wrapper was present — detectManifestActions gated Gradle detection solely on existsSync(cwd/'gradlew'). This is inconsistent with socket manifest gradle, whose bin already falls back to gradle on PATH when there's no wrapper. So a wrapper-less Gradle project worked with socket manifest gradle but was silently ignored by --auto-manifest, regardless of any bin set in socket.json (detection never passed, so generation was never reached).

Fix

Detect Gradle by its build script — build.gradle / build.gradle.kts — instead of the wrapper, mirroring how the other ecosystems are detected (pom.xml for Maven, build.sbt for sbt). The wrapper is not a build descriptor; the Maven analog would be mvnw, which we deliberately don't check.

Empirically validated against a corpus of real Gradle/Kotlin projects (kafka, RxJava, elasticsearch, okhttp, leakcanary, Kotson, klaxon): every Gradle root/subproject has a build.gradle(.kts) — 0 of 15 settings.gradle dirs lacked one — so settings.gradle isn't needed as an extra marker and dropping the gradlew requirement regresses no real project.

Testing

• Unit tests in detect-manifest-actions.test.mts: detects build.gradle / build.gradle.kts, detects a wrapper-less project, does not detect from a bare gradlew, and honors the disabled flag. Updated the existing bazel+gradle co-detect test to use build.gradle.
• End-to-end: socket manifest auto on a wrapper-less build.gradle project now detects Gradle and writes .socket.facts.json (8 components); previously it was skipped.
• pnpm check:tsc clean; 11/11 detector tests pass.

Closes REA-622. Part of the same Unreleased version as the REA-519 config-transparency PR (#1398).

---

Note

Low Risk
Narrow change to manifest auto-detection heuristics with tests; may surface Gradle generation on dirs that previously had only gradlew without a root build script.

Overview
Gradle auto-manifest detection now keys off build.gradle / build.gradle.kts instead of a gradlew wrapper, so socket manifest auto and scan create --auto-manifest treat wrapper-less projects the same as explicit socket manifest gradle (which can use gradle on PATH).

A repo with only gradlew and no build script is no longer flagged as Gradle. The Unreleased changelog documents the behavior change, and unit tests cover both scripts, wrapper-only negatives, and the socket.json disable flag.

^{Reviewed by Cursor Bugbot for commit 10a0aa8. Configure here.}

[Martin Torp (mtorp)]

One case this regresses: Gradle only requires a settings file at the build root — a root build.gradle(.kts) is optional, and modern Kotlin-DSL multi-module projects often have just settings.gradle.kts at the root (all build scripts in subprojects / convention plugins in buildSrc). A repo like that with a gradlew wrapper was detected before this PR and is now silently skipped — and the new "does not detect gradle from a gradlew wrapper alone" test locks that in.

The corpus check in the PR body (kafka, RxJava, elasticsearch, okhttp, …) skews toward older/Groovy-heavy projects that do keep a root build script, so it doesn't cover this layout.

Suggestion: add settings.gradle / settings.gradle.kts to the marker check alongside build.gradle(.kts). That closes both the regression and the remaining wrapper-less gap (settings-only root, gradle on PATH), and it's arguably the more principled marker anyway since Gradle defines the settings file as the build-root marker. Fine as a follow-up.

[Jeppe Fredsgaard Blaabjerg (jfblaa)]

You're right, and my corpus (older/Groovy-heavy projects) masked it — a Kotlin-DSL multi-module root can have only settings.gradle.kts and no root build script, and with a wrapper it was detected before this PR.

Fixed in 2ca6f43: detection now also checks settings.gradle / settings.gradle.kts alongside build.gradle(.kts) — the build-root marker, as you note, so it's the more principled check and it closes both the regression and the settings-only-root gap (no wrapper, gradle on PATH). Added tests for a plain settings.gradle and for the exact regression layout (settings.gradle.kts + gradlew, no build.gradle).

The does not detect gradle from a gradlew wrapper alone test stays, but it no longer locks in the regression: it now only asserts that a bare wrapper with no build descriptor (no build.gradle, no settings.gradle) isn't treated as a project — consistent with detecting by descriptor rather than wrapper. Updated the changelog entry too.