Dependency resolution for gradle projects in CI pipelines

Problem to solve

Based on the completed spike validation, we need to implement Gradle dependency auto-resolution for the new Dependency Scanning Job Orchestration architecture. The spike confirmed that a gradlew-first approach with Java 17 can achieve 50% project coverage (matching current Gemnasium analyzer performance) while simplifying our maintenance overhead.

Proposal

Implement a Gradle dependency resolution job that uses native gradle dependencies command with a simplified runtime environment, replacing the current multi-version Gemnasium approach.

Architecture Overview

Runtime Environment:

• Base image: Java 17 + Gradle 8 (single version)
• Strategy: gradlew-first with system Gradle fallback
• Dependencies: git, curl for gradlew downloads

Resolution Strategy:

1. Primary: Execute ./gradlew dependencies if wrapper exists
2. Fallback: Use bundled gradle dependencies for projects without wrapper
3. Combined coverage: ~65% success rate (union of both approaches)

Success Criteria

• Achieve 50% project success rate (parity with current Gemnasium)
• Handle both single-module and multi-module projects
• Support air-gapped environments
• Provide clear error messages for unsupported project configurations

Technical Constraints

Known Limitations:

• 50% success rate ceiling due to Gradle ecosystem fragmentation
• Gradle < 7.0 incompatible with Java 17 (15% of projects)
• Multi-module projects may require per-module resolution (20% of projects)
• Project maintenance issues affect 15% of projects

Air-gapped Support:

• Requires pre-populated Gradle distribution cache
• Needs access to dependency repositories or mirrors
• gradlew downloads must be available locally

Related Work

• Spike validation: #586914 (closed)
• Maven implementation: #584580 (closed)