Feat: Publish build artefacts and drop dead input

[ModeSevenIndustrialSolutions]

Summary

The build lane threw its output away. Adds opt-in build artefact publication to both the Maven and Gradle lanes, and removes an input that has never worked.

The gap

Run 30466479894 (ONAP cps, 24-module reactor) produced four artefacts:

Artefact	Contents
maven-junit-reports	Surefire/Failsafe XML
sbom-files	CycloneDX SBOM
grype-scan-results	Vulnerability findings
repository-metadata-…	Run metadata

Not one jar. Every artefact the reactor built died with the runner. That blocks anything downstream of a build — publish/stage, container builds, CSIT — and leaves a human debugging a failed run with no way to fetch the jar it produced.

upload_build_artifacts, off by default

Off by default is a deliberate call, and the one thing here most worth pushing back on. The packaged output is large and most verify lanes never read it back, so uploading unconditionally would charge storage to every consumer in order to serve a minority. The cases that want it are real, so this is a switch rather than an omission.

build_artifact_retention_days defaults to 7, against the SBOM's 45: build output is reproducible from the commit, so it is a convenience rather than a record.

Two shapes, and why the artefact says which

A Maven build can yield either, and they are not interchangeable:

• A deploy phase writes a repository layout to m2repo (groupId/artifactId/version/...) — the layout Nexus staging and nexus-publish-action consume, via files_path.
• Any other phase leaves packaged output scattered through the reactor's target/ directories.

The collect step prefers m2repo when present and records which it took in the artefact name — maven-build-artifacts-m2repo or maven-build-artifacts-reactor — so a consumer knows what it has without inspecting the contents.

Worth flagging: this lane's default mvn_phases is clean install, so the reactor shape is what most callers will get. m2repo appears only when a caller asks for deploy. I deliberately did not change the default phase to deploy — that is a real behaviour change for every consumer and belongs in its own discussion, not smuggled into an artefact fix.

Collection takes files sitting directly in target/ (or build/libs for Gradle), so target/classes/ and target/dependency/ are left behind.

Also surfaces m2repo_exists, m2repo_path and artifact_count as build-job outputs. maven-build-action already computed these and documented them as "for downstream publish/stage actions"; the workflow simply discarded them.

Dead input removed

Both lanes passed github_summary: 'true' to build-metadata-action, which has no such input:

##[warning]Unexpected input(s) 'github_summary', valid inputs are
['path_prefix', 'output_format', 'include_environment', 'use_version_extract',
 'verbose', 'artifact_upload', 'artifact_name_prefix', 'artifact_formats',
 'validate_output', 'strict_validation', 'export_env_vars',
 'python_offline_mode', 'python_eol_timeout', 'python_eol_max_retries']

GitHub warned and ignored it on every run, so the metadata summary the comment promised has never rendered. The neighbouring repository-metadata-action call does take github_summary, which is the likely source of the copy — that one is correct and untouched. Comments corrected so they no longer describe a feature that does not exist.

Validation

• prek run --all-files — every hook passes, including actionlint, shellcheck, workflow schema validation and the timeout-minutes check

• zizmor --persona auditor --min-severity informational .github/workflows/ — no findings, all seven workflows parsed without warnings

• Collection logic exercised locally against fixture trees, all three paths:

  Case	Result
  Reactor, nested modules	shape=reactor count=3 — picked up dmi-stub/dmi-stub-service/target/, correctly skipped target/classes/ and target/dependency/
  m2repo present	shape=m2repo count=2 — layout preserved
  Nothing built	shape=none count=0 — upload step skips, no spurious failure

Follow-up

ONAP cps and cps-ncmp-dmi-plugin callers will set upload_build_artifacts: true once this tags.

[Copilot]

Pull request overview

Adds an opt-in mechanism to publish packaged build outputs (jars/wars/ears) from the reusable Maven and Gradle verify workflows, and removes a non-existent github_summary input previously passed to build-metadata-action.

Changes:

• Introduces upload_build_artifacts and build_artifact_retention_days inputs, plus artifact collection/upload steps, for both Maven and Gradle verify lanes.
• Removes the invalid github_summary input from lfreleng-actions/build-metadata-action usage and updates surrounding comments/docs accordingly.
• Documents the build-artifact “shape” behavior (Maven m2repo vs reactor target/, Gradle build/libs) and adds example caller snippets.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
examples/maven/build-test/github.yaml	Documents the new opt-in build artifact upload inputs for Maven callers.
examples/gradle/build-test/github.yaml	Documents the new opt-in build artifact upload inputs for Gradle callers.
docs/BRIEF.md	Adds design-brief documentation for build artifact publication behavior and shapes.
.github/workflows/maven-build-test.yaml	Adds inputs, surfaces build outputs, removes dead github_summary input, and implements Maven artifact collection/upload.
.github/workflows/gradle-build-test.yaml	Adds inputs, removes dead github_summary input, and implements Gradle artifact collection/upload.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

.github/workflows/maven-build-test.yaml:510

• The upload step uses always() and only checks steps.build-artifacts.outputs.count != '0'. If the preceding Collect build artefacts step fails before writing outputs, count will be empty and this condition will still evaluate true, causing this step to run and fail (or fail with a confusing error), potentially obscuring the original failure. Gate the upload on the collect step succeeding while still allowing uploads on failed builds.

        if: ${{ always() && inputs.upload_build_artifacts && steps.build-artifacts.outputs.count != '0' }}

.github/workflows/gradle-build-test.yaml:448

• Same issue as the Maven lane: with always() and only a count != '0' check, a failure in Collect build artefacts can leave count empty and still trigger this upload step, causing extra noise and potentially masking the root cause. Gate the upload on the collect step outcome.

        if: ${{ always() && inputs.upload_build_artifacts && steps.build-artifacts.outputs.count != '0' }}

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

.github/workflows/maven-build-test.yaml:514

• If the "Collect build artefacts" step fails before writing count to $GITHUB_OUTPUT (e.g., invalid path_prefix), steps.build-artifacts.outputs.count will be empty, which still satisfies != '0' and causes the upload step to run and fail with a confusing if-no-files-found error. Gate the upload on the collect step succeeding as well.

        if: ${{ always() && inputs.upload_build_artifacts && steps.build-artifacts.outputs.count != '0' }}

.github/workflows/gradle-build-test.yaml:448

• If the "Collect build artefacts" step fails before writing count to $GITHUB_OUTPUT (e.g., invalid path_prefix), steps.build-artifacts.outputs.count will be empty, which still satisfies != '0' and causes the upload step to run and fail with a confusing if-no-files-found error. Gate the upload on the collect step succeeding as well.

        if: ${{ always() && inputs.upload_build_artifacts && steps.build-artifacts.outputs.count != '0' }}