Conversation
MergeCommand now calls CycloneDXUtils.FlatMerge/HierarchicalMerge with MergeStrategy.Default() when built against a library that has it (#if NET8_0_OR_GREATER, matching the library's own guard -- CLI is net10.0-only today but this keeps the two projects' conditional compilation symmetric and self-documenting), falling back to the plain overload otherwise. No new CLI flags: strategy toggles are not yet exposed at the command-line layer, so this only changes default merge behavior, not the command's surface. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
Adds a "rename-entity" command that renames a bom-ref and every back-reference to it throughout a BOM document, built on the library's new BomRefWalker-based Bom.RenameRef(old, new) API. Follows current System.CommandLine conventions (System.CommandLine.NamingConventionBinder, not the older System.CommandLine.Invocation namespace) and matches Convert/ MergeCommand's internal (not public) visibility. Verified end-to-end against a real fixture: renaming a component's bom-ref correctly rewrites both the dependsOn back-reference and the dependency's own ref entry, and stamps fresh SerialNumber/Timestamp/ Tools metadata via BomMetadataUpdate/BomMetadataReferThisToolkit. Wired into Program.cs (alphabetical position, between Merge and Sign), guarded by #if NET8_0_OR_GREATER to match the library capability it depends on. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
Follows MergeTests.cs conventions: direct handler call, TempDirectory, Snapshooter with serialNumber/timestamp stripped (plus the tools list, whose contents are build/environment-specific -- assembly versions and "testhost" vs. the real CLI name under `dotnet test`). Covers a JSON and an XML output round-trip of the rewrite-identifier-and-back-refs case, plus a no-op case when the requested old-ref isn't present. Full suite: 132 passed / 0 failed (129 pre-existing + 3 new). Signed-off-by: Jim Klimov <jimklimov@gmail.com>
…usal merge gains --component-conflict-resolution <KeepSeparate|Squash_UpgradeScope|Squash_DowngradeScope|Squash_RenameByScope>, defaulting to the library's MergeStrategy.Default() (Squash_UpgradeScope) when not specified. This closes a pre-existing gap: the library-side strategy was never selectable from the CLI at all -- it was always hardcoded to Default() internally. Verified end-to-end: merging two BOMs where the same component is "required" in one and "excluded" in the other with --component-conflict-resolution Squash_RenameByScope produces two distinct components (lp:scope=Required / lp:scope=Excluded) with each source's dependsOn correctly pointing at its own variant. rename-entity now catches the InvalidOperationException Bom.RenameRef throws when the requested new-ref collides with an existing identifier, reporting it as a clean parameter-validation error instead of an unhandled crash. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
This lets callers pass files listing BOM filenames (one per line, or 0x00-separated for the --input-files-nul-list variant, e.g. from `find -print0`) instead of one --input-files argument per BOM, to avoid OS/shell command-line length or argument-count limits when merging many BOMs, a real constraint once the number of input files grows large. Entries are deduplicated against --input-files and each other as they are collected. Non-absolute paths are resolved relative to the current working directory. No library changes needed -- this feature only builds a longer input-file list before the existing InputBoms(...) call. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
Previously, when a flat merge specified a subject component (--group/ --name/--version), MergeCommand set Metadata.Component directly and never called the FlatMerge overload that accepts a subject component. As a result the merged document's dependency graph never linked the subject to the components each input BOM contributed -- no "<dependency ref="subject"><dependsOn>...` entry ever appeared, unlike a hierarchical merge with the same options. Calling FlatMerge(inputBoms, bomSubject, ...) instead lets the library build that dependency entry itself (namespacing the subject's bom-ref and linking it to each input BOM's own metadata component), matching what hierarchical merge already does. The "pick the first input BOM's component as a default" fallback still runs, but only when no subject was requested at all. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
Replaces manually setting Version/SerialNumber/Timestamp inline with Bom.BomMetadataUpdate(true) and Bom.BomMetadataReferThisToolkit(). The manual version never recorded which library/tool produced the merged document at all -- Metadata.Tools was left exactly as whichever input BOM happened to contribute one, or absent entirely. The merged document now carries an entry for this library and the running program, the same way validate/convert/sign already leave a traceable record of what processed a document. Updates MergeTests' snapshot-cleanup regex to also strip the tools block before comparison, since its contents (assembly name/version) are build-environment-specific -- same treatment already used for other commands' tests. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
Calls the library's new CleanupMetadataComponent/CleanupEmptyLists on the merged document. Complements the library-side change (which already covers this for a merge that requests an explicit BOM subject): when MergeCommand falls back to picking the first input BOM's own metadata component as the subject, that same component can also be present in the merged Components list, producing two entries with the same bom-ref -- a specification violation the library-level cleanup couldn't see, since the CLI's fallback selection happens after the library call returns. CleanupEmptyLists also drops now-empty top-level lists (e.g. an empty "vulnerabilities": []) that a flat merge of BOMs with no vulnerabilities previously left in the output. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
Validates the merged document against its own spec version before writing it out. --validate-output aborts (does not write the file) if validation fails; --validate-output-relaxed still writes the file -- useful for troubleshooting a failing merge -- but the command still reports failure via its exit code either way. Without either flag, behavior is unchanged (no validation is performed). Signed-off-by: Jim Klimov <jimklimov@gmail.com>
FlatMerge/HierarchicalMerge never set SpecVersion on their result (it defaults to v1_0). The only place merge ever assigned a real value was inside CliUtils.OutputBomHelper's write path, which runs after the --validate-output/--validate-output-relaxed check -- so validation was always checking a throwaway spec version, never the one --output-version actually requested (or the library's current version, if it wasn't given at all). A merge targeting an older schema version could pass --validate-output cleanly while the version that mattered was never actually tested. Assigns outputBom.SpecVersion from --output-version (falling back to SpecificationVersionHelpers.CurrentVersion, matching OutputBomHelper's own default) before the validate-output block, so validation reflects what will actually be written. Signed-off-by: Jim Klimov <jimklimov@gmail.com>
FlatMerge only unions each input's own Components and Dependencies -- it never guarantees the result stays one connected graph. A flat merge of many independently-generated documents (one per module in a large multi-module build being the common case) can easily leave some of them unreachable from the merged document's subject: still present in the flat components list, but invisible to any consumer that walks the dependency graph from the root instead (Dependency-Track being a common example). Confirmed on a real ~360-module merge: 89 components never targeted by any dependsOn edge, all silently invisible to a graph-walking consumer despite validating cleanly. --attach-dangling-components runs the library's new Bom.AttachDanglingComponents after the merge, reporting what it found grouped by scope bucket. --attach-dangling-components-ref lets the caller name an existing bom-ref to attach under (falling back to the merge subject if not given or not found). Signed-off-by: Jim Klimov <jimklimov@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds
merge --attach-dangling-components, exposing the library'sBom.AttachDanglingComponents(): aftera merge, attach components that ended up with no incoming dependency edge somewhere in the dependency
graph, so the merged document's dependency tree has no gaps.
Why
New capability — no earlier CLI PR proposed this. Depends on
cyclonedx-dotnet-library#449. Stacked
on #514 (
merge-validate-output) — must merge first. Includes regression tests(
AttachDanglingComponentsTests.cs).