Reusable lanes get no PR-time end-to-end testing

[ModeSevenIndustrialSolutions]

Problem

.github/workflows/testing.yaml is triggered by workflow_dispatch: only:

on:
 workflow_dispatch:

It never runs on pull requests. The Maven and Gradle reusable lanes therefore have no PR-time end-to-end validation. PRs get the meta-checks (Semantic Pull Request, zizmor, aislop, SHA-pinning, DCO) but the reusable workflows themselves are never exercised.

Its last recorded run was 2026-08-25, and it failed.

Why this matters

This is very likely why #47 went unnoticed: the Maven lane has been producing an SBOM containing a single unversioned dependency, and Grype has been reporting No vulnerabilities found against it. A green PR meant nothing had been tested.

It is also a prerequisite for two other pieces of work:

• Maven SBOMs miss 93% of the dependency graph #47 — there is nowhere to validate the cyclonedx-maven-plugin fix at PR time
• Toggle opt-out paths are untested across the estate workflows-template#57 — toggle opt-out coverage has nothing to hang off in this repo

Compare with python-workflows

python-workflows/testing.yaml gets this right, and its comment explains why workflow_dispatch was deliberately excluded there:

on:
 # No workflow_dispatch: a manual run happens on the default branch,
 # which would hand this job a cache token with write access to the
 # default-branch scope while it builds and tests third-party
 # consumer repositories. Untrusted code from those repositories
 # could then poison caches that later runs restore (CWE-349).
 # Pull request runs write only to their own cache scope.
 pull_request:
 branches: ['main']

So this repo has not merely omitted pull_request — it uses exactly the trigger python-workflows rejected on cache-poisoning grounds, and omits the one it adopted. Worth fixing in both directions.

Suggested work

1. Switch to pull_request: branches: ['main'], matching python-workflows, and carry the same explanatory comment about why workflow_dispatch is omitted.
2. Repoint at the lightweight fixtures, as the file's own TODO already asks:

   # TODO: repoint to a lightweight test-maven-project fixture.
   repository: 'apache/maven'
   

   test-maven-project exists in the org. Building apache/maven on every PR is both slow and a poor signal. (test-gradle-project does not appear to exist yet — the Gradle lane currently points at onap/portal-ng-preferences and may need a fixture created.)
3. Fix whatever caused the 2026-08-25 failure.

Sequencing note

Doing this before #47 is worth considering: it would let the SBOM fix be validated by CI rather than by hand, and the fixture repoint gives a fast feedback loop for a change that alters SBOM contents substantially. Conversely, be aware that fixing this may surface pre-existing failures that #47 then resolves — the near-empty SBOM currently passes trivially.

Related

• Maven SBOMs miss 93% of the dependency graph #47 — Maven SBOM fidelity (this unblocks its validation)
• Gradle SBOMs need a resolved dependency graph #48 — Gradle SBOM (will need a test-gradle-project fixture)
• Toggle opt-out paths are untested across the estate workflows-template#57 — toggle opt-out coverage