☕ Java Workflows

Reusable GitHub Actions workflows that build, test and scan JVM projects for the Linux Foundation. This repository covers both Maven and Gradle projects, porting the Jenkins + global-jjb pipeline onto GitHub Actions. This initial release provides the verify lane (build, test, SBOM and Grype scan); docs/BRIEF.md tracks the merge and release lanes that follow later. The workflows keep the harden-runner block posture, pinned action SHAs and dual Gerrit/GitHub trigger model of workflows-template.

Maven and Gradle families

GitHub resolves callable workflows from the flat .github/workflows/ directory, so the two toolchains split by filename prefix rather than by subfolder:

Workflow	Toolchain	Purpose	Caller trigger
.github/workflows/maven-build-test.yaml	Maven	Build, test, SBOM and Grype scan	Pull request
.github/workflows/gradle-build-test.yaml	Gradle	Build, test, SBOM and Grype scan	Pull request

These are workflow_call reusable workflows; they carry no trigger of their own. "Caller trigger" is the event on which the shipped examples/ callers invoke them (pull request for the verify lane).

Verify lane

The maven-build-test.yaml and gradle-build-test.yaml workflows are complete. A repository-metadata job runs in parallel as an informational step that does not gate the build. After build, the test and SBOM/Grype branches run in parallel (jobs in { } run concurrently; -> denotes sequence):

build -> { tests | sbom -> grype }

The build job detects the project's Java version through build-metadata-action, runs the build with maven-build-action or gradle-build-action, gathers the JUnit XML the build emits, and uploads it as an artefact. The tests job renders that XML through junit-test-report-action into the job summary (it does not create a check-run) and runs even when the build fails, so test failures still surface a report. The sbom job generates a real CycloneDX SBOM with sbom-action (syft static analysis of the checked-out tree) and feeds the JSON document to grype under the grype_fail_on gate.

The generic template's standalone audit job does not appear here: on the JVM, dependency-risk auditing is the SBOM/Grype chain plus the separate Sonatype CLM lane, and the build tool (surefire/failsafe or the Gradle test task) runs the tests as part of its own lifecycle.

Usage

Copy a caller from examples/ into your project's .github/workflows/ directory and replace the placeholder uses: SHA with a pinned release. Each caller ships in two forms:

• github.yaml — a plain GitHub-native caller. The shipped verify callers are pull-request triggered.
• gerrit.yaml — a Gerrit-wrapped caller for projects where Gerrit is the source of truth, integrating with gerrit_to_platform voting/commenting.

examples/
  maven/
    build-test/          { github.yaml, gerrit.yaml }
  gradle/
    build-test/          { github.yaml, gerrit.yaml }

Inputs are optional and default to the canonical behaviour; read the inputs: block at the top of each workflow file for the documented list.

Gerrit support

The reusable workflows are Gerrit-aware: a caller that sets the gerrit_refspec input checks out the change with checkout-gerrit-change-action in place of actions/checkout. Vote and comment casting live in the gerrit.yaml caller examples (clear vote → run → report vote for verify), never inside the reusable workflows.

Testing

.github/workflows/testing.yaml exercises the Maven and Gradle verify workflows through their local paths, so it validates the current branch. Both self-test jobs run on workflow_dispatch and stay skipped on pull requests until one prerequisite lands: dedicated lightweight fixtures. The released action pins and the toolchain egress endpoints in the central harden-runner allow-list (as of .github v0.7.0) are already in place. See docs/BRIEF.md for detail.

Design

Read docs/BRIEF.md for the design decisions: the Maven/Gradle split, the verify-lane wiring, the removed audit job, the planned merge/release lanes, and the action-pinning policy.