fix: report what the SBOM could not describe - #922
Conversation
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Duplication | 5 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
A component whose POM could not be obtained, read, or completed from its parent produced the same entry as one that resolves and declares nothing: no licenses, no publisher, no error. Three of the paths that end there returned null without a log line, and the unresolved artifact result they discarded carries the reason Gradle reported. A declared dependency that does not resolve at all is worse off: the lenient artifact view drops it, so the component is absent from the document, and the only trace was a line logged at info. Such a component now carries a cdx:gradle:metadata:unresolved property naming what happened, one of pom-unresolved, pom-unparseable, parent-unresolved, parent-unparseable or model-incomplete, and the reason goes to the log at warning level. The dropped dependency is logged at warning level too, since the document cannot carry the fact. Healthy builds produce unchanged documents. What a POM declares is now reported even where the effective model could not be completed. Maven replaces the inherited values instead of merging into them, so a component's own declarations are complete without the model, and discarding them lost information the build had in hand. Which of the model's inputs failed is not reported, so a failing import cannot be told from a failing parent for a component that declares one. The parent is named in that case, and the ADR states the limit. failOnIncompleteSbom, off by default, stops the build instead and names every component it could not account for. A failed task stores nothing, so a document built from a bad repository answer is never handed to another machine through the build cache. It stays off by default because a component carrying no POM is legitimate in an artifact-only or Ivy repository and arrives here exactly as one whose POM a repository failed to return. allowedIncompleteComponents names the components a build expects to be incomplete, as full-match regular expressions over group:name:version, and suppresses the failure alone: the property and the log still report what happened. ADR 0009 records the decision, CONTEXT.md gains the term, and UnresolvedMetadataSpec covers every path against a fixture repository of twelve components. Signed-off-by: David Sondermann <david.sondermann@hivemq.com>
22bf05c to
6c98d13
Compare
skhokhlov
left a comment
There was a problem hiding this comment.
I agree that the metadata visibility problem is worth fixing. Consumers should be able to distinguish unavailable metadata from a component that declares none. Preserving readable metadata when effective-model construction fails also makes sense.
I’d like the following changes before merging:
- Keep this PR focused on metadata reporting. Please defer
failOnIncompleteSbomandallowedIncompleteComponentsto a separate proposal. They introduce a broader completeness policy that needs discussion of dependency resolution, artifact failures, metadata failures, and exceptions. Agreement with the problem described in #921 does not imply acceptance of that proposed API. - Avoid inferring which model input failed. The
okparentbadimportfixture has a healthy parent and a broken imported BOM, but currently reportsparent-unparseable. Usemodel-incompletewhen effective-model construction fails without an established cause. We should not publish a more specific diagnosis than the evidence supports, especially since these values become part of the SBOM output contract. - Use the
cdx:mavennamespace and register the property before release. This represents Maven metadata, regardless of which build tool reports it. Please agree the property name and value meanings through the property taxonomy; the cdx rules prohibit unofficial names under that namespace.
Keep the missing-POM behavior simple: an attempted lookup that finds no usable POM should report pom-unresolved, including intentional artifact-only or Ivy dependencies. This indicates unavailable metadata, not a defective component, and should not fail the build. No repository-specific exceptions are needed.
Please update the tests, README, glossary, and proposed ADR to match this narrower scope.
Fixes #921.
Reproducer: https://github.com/Donnerbart/cyclonedx-metadata-reproducer