No test-gradle-project fixture for the Gradle lane

[ModeSevenIndustrialSolutions]

Problem

There is no test-gradle-project fixture in the org. The Maven lane has lfreleng-actions/test-maven-project; the Gradle lane does not have an equivalent, so its self-test builds a pinned commit of onap/portal-ng-preferences.

That has three costs:

1. Egress must stay in audit mode. A large upstream project's footprint exceeds the allow-listed toolchain set, so the Gradle lane cannot run under block while the Maven lane now can.
2. Slow PR feedback, since it builds a full Spring Boot service on every pull request.
3. No control over the shape of the fixture. We cannot add a deliberately failing test, a multi-project reactor, or a Kotlin DSL variant to exercise specific lane behaviour.

What the fixture should provide

Mirror what test-maven-project already does well:

• Multi-project build (Gradle equivalent of the parent/core/app reactor), since multi-project handling is where SBOM generation and reporting most often break
• A Failing*Test class excluded by default, enabled by a property or task, so consumers can exercise soft-fail inputs and report rendering against a genuinely failing build — test-maven-project does this via surefire.excludes and a failing-tests profile
• Minimal dependencies (JUnit only) so the egress footprint is the allow-listed toolchain set and the lane can run under block
• Estate conventions: REUSE/SPDX headers, .pre-commit-config.yaml, .gitlint, .yamllint, LICENSES/, SECURITY.md

Worth deciding up front

Groovy or Kotlin DSL — or both? build.gradle and build.gradle.kts behave differently for plugin application, which matters directly to #48 (Gradle SBOM via init-script injection). Two fixture variants, or one fixture with both module styles, would let #48 be validated properly rather than against one dialect.

With or without gradle.lockfile? Dependency locking is opt-in and most real projects skip it, so the default fixture should have no lockfile — that is the realistic case and the one that currently produces an empty SBOM. A second locked variant would be useful for proving the contrast.

Related

• Reusable lanes get no PR-time end-to-end testing #49 — PR-time self-testing; the Gradle lane keeps its upstream target and audit egress until this lands
• Gradle SBOMs need a resolved dependency graph #48 — Gradle SBOM resolution; needs this fixture to validate init-script injection
• lfreleng-actions/test-maven-project — the model to follow