[guillaume-dequenne]

Part of CLP-897

Summary

• Split the Maven build/deploy producer from the NEXT analysis consumer.
• Upload the exact Maven target outputs as a three-day artifact and restore them for the scan.
• Reuse the same build number and Maven scan configuration so the analysis remains equivalent.
• Keep promotion and releasability gated by the scan.

Dependency

• Scanner-only mode is provided by PREQ-8698 Add skip build option to maven build ci-github-actions#348 and is currently pinned to its reviewed commit. Re-pin to v1 or v2 once that PR is merged.

Validation

• Parsed the updated workflow as YAML.
• Ran actionlint, accounting for existing Sonar-specific workflow extensions.
• Ran git diff --check.

[hashicorp-vault-sonar-prod]

CLP-897

[gitar-bot]

💡 Performance: Scan artifact uploads ~hundreds of MB of Node.js runtimes every run

The upload step takes path: '**/target', which pulls in runtime/target as well. The runtime module has no sources. Its build downloads six Node.js binaries (darwin-arm64/x64, linux-arm64/x64/musl, win-x64), xz-compresses them, copies them into target/classes as resources, and packs them into the module jar. So every run, PRs included, uploads and then downloads two copies of the compressed runtimes (several hundred MB) and keeps them for 3 days. The scan never uses them: there is nothing to analyze in runtime, and the skip-build check only needs some */target/classes directory, which maven-plugin/target already provides. Excluding the binary payload keeps the analysis the same and removes most of the transfer.

Leave the Node.js runtime payload out of the scan artifact:

- name: Upload build output for scanning
  uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
  with:
    name: build-output-${{ steps.build.outputs.BUILD_NUMBER }}
    path: |
      **/target
      !runtime/target/**/*.xz
      !runtime/target/*.jar
    retention-days: 3

_{Was this helpful? React with 👍 / 👎}

[sonarqube-next]

Quality Gate passed for 'NodeJS Maven Plugin'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[gitar-bot]

Code Review 👍 Approved with suggestions 0 closed / 1 findings

🟡 Medium risk · The CI workflow separates Maven builds from scans and gates promotion on both.

Workflow refactored to split Maven build from NEXT analysis, uploading build artifacts for reuse across jobs while maintaining equivalent scanning configuration. Consider excluding runtime/target from artifact uploads to avoid transferring hundreds of MB of Node.js binaries that the scan doesn't use.

💡 Performance: Scan artifact uploads ~hundreds of MB of Node.js runtimes every run

📄 .github/workflows/build.yml:34-39

The upload step takes path: '**/target', which pulls in runtime/target as well. The runtime module has no sources. Its build downloads six Node.js binaries (darwin-arm64/x64, linux-arm64/x64/musl, win-x64), xz-compresses them, copies them into target/classes as resources, and packs them into the module jar. So every run, PRs included, uploads and then downloads two copies of the compressed runtimes (several hundred MB) and keeps them for 3 days. The scan never uses them: there is nothing to analyze in runtime, and the skip-build check only needs some */target/classes directory, which maven-plugin/target already provides. Excluding the binary payload keeps the analysis the same and removes most of the transfer.

Leave the Node.js runtime payload out of the scan artifact

- name: Upload build output for scanning
  uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
  with:
    name: build-output-${{ steps.build.outputs.BUILD_NUMBER }}
    path: |
      **/target
      !runtime/target/**/*.xz
      !runtime/target/*.jar
    retention-days: 3

🤖 Prompt for agents

Code Review: Workflow refactored to split Maven build from NEXT analysis, uploading build artifacts for reuse across jobs while maintaining equivalent scanning configuration. Consider excluding `runtime/target` from artifact uploads to avoid transferring hundreds of MB of Node.js binaries that the scan doesn't use.

1. 💡 Performance: Scan artifact uploads ~hundreds of MB of Node.js runtimes every run
   Files: .github/workflows/build.yml:34-39

   The upload step takes `path: '**/target'`, which pulls in `runtime/target` as well. The `runtime` module has no sources. Its build downloads six Node.js binaries (darwin-arm64/x64, linux-arm64/x64/musl, win-x64), xz-compresses them, copies them into `target/classes` as resources, and packs them into the module jar. So every run, PRs included, uploads and then downloads two copies of the compressed runtimes (several hundred MB) and keeps them for 3 days. The scan never uses them: there is nothing to analyze in `runtime`, and the skip-build check only needs some `*/target/classes` directory, which `maven-plugin/target` already provides. Excluding the binary payload keeps the analysis the same and removes most of the transfer.

   Fix (Leave the Node.js runtime payload out of the scan artifact):
   - name: Upload build output for scanning
     uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
     with:
       name: build-output-${{ steps.build.outputs.BUILD_NUMBER }}
       path: |
         **/target
         !runtime/target/**/*.xz
         !runtime/target/*.jar
       retention-days: 3

Verification

Functional validation No results

Rules No rules evaluated

Auto-approval Not enabled

Set up

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}