Helm OCI build-info modules can merge into Docker modules when ids match

Start by locating the helper-level tests and implementations for addArtifactsInBuildInfo and appendModuleInExistingBuildInfo. Reproduce a Docker and Helm module with the same name:version, then verify that modules merge only when both Type and Id match and that the result is independent of processing order.

Describe the bug

When collecting build-info for Helm OCI operations, Helm modules can be incorrectly merged into Docker modules if both modules share the same name:version.

The issue is caused by Helm build-info merge helpers using only module.Id to identify an existing module. In mixed-package builds, that assumption is too weak because modules from different ecosystems can legitimately have the same ID while still representing different module types.

Current behavior

If a Docker module already exists in the build-info with the same name:version as a Helm OCI module, Helm artifacts and/or module data can be merged into the Docker module instead of remaining in a separate Helm module.

This leads to incorrect build-info output and order-dependent behavior.

Example of the problematic flow:

• Docker produces a module with ID my-app:1.0.0
• Helm OCI later produces a module with the same ID my-app:1.0.0
• Helm build-info helpers match by Id only
• Helm artifacts are appended to the Docker module or the module merge result depends on insertion order

Observed impact:

• build-info can contain merged module content from different package types
• the final output is inconsistent depending on whether Docker or Helm is processed first
• the generated build-info does not accurately represent the published artifacts

Reproduction steps

One reproducible scenario is:

1. Start with build-info that already contains a Docker module with:
   • Type = docker
   • Id = my-app:1.0.0
2. Run a Helm OCI flow that produces a Helm module with:
   • Type = helm
   • Id = my-app:1.0.0
3. Let the Helm helpers append artifacts or merge modules into the existing build-info
4. Inspect the resulting modules in the saved build-info

The issue can be reproduced directly in helper-level tests around:

• addArtifactsInBuildInfo
• appendModuleInExistingBuildInfo

Expected behavior

Modules should be merged only when both the module type and the module ID match.

That means:

• same Type + same Id -> merge
• different Type + same Id -> stay separate

The resulting build-info should be stable and independent of processing order.

JFrog CLI-Core version

v2.60.1-0.20260414083544-243b4d55328b

JFrog CLI-Artifactory version

Current checkout from this repository based on:

github.com/jfrog/jfrog-cli-artifactory

JFrog CLI version (if applicable)

jf version 2.100.0

Operating system type and version

macOS darwin arm64

JFrog Artifactory version

N.A

Additional context

• This report is intentionally focused on the bug itself.
• The bug is in build-info module merge semantics, not in Artifactory storage-path resolution.
• A correct fix should merge modules only when both Type and Id match.