You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit c7214a7
Browse filesBrowse the repository at this point in the historyBrowse files
fix(manifest): block on a non-blocking JVM failure whose module resolved nowhere (#1647)
* fix(manifest): block on a non-blocking JVM failure whose module resolved nowhere
Variant ambiguity is lenient because the module is almost always
captured through another configuration. The report now checks that: an
ambiguous module that resolved in no configuration of its project is
missing from the SBOM, so it blocks. Reachability scans also name
--reach-continue-on-install-errors next to ignoreUnresolved, since
reachability cannot install a dependency that was let through.
* fix(manifest): judge a lenient JVM failure per project
Failures were merged by coordinate across projects before checking
whether the module resolved, so one project that resolved it kept the
failure lenient for another project whose SBOM lacked it. Blocking is
now decided per failure, and failures aggregate by coordinate, category
and that decision.
Copy file name to clipboardExpand all lines: CHANGELOG.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,6 +15,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
15
15
- JVM dependencies whose jars cannot be fetched, or are gone from disk, no longer reach reachability analysis looking resolved without code.
16
16
- One unresolvable Maven dependency no longer strips the jar paths from every other dependency of its build, which made reachability analysis call their vulnerabilities unreachable. Jars that cannot be fetched are reported with their real cause, Maven 4 included.
17
17
- Maven dependencies with missing or invalid POMs are reported in every module that uses them, `system`-scope jars reach reachability analysis, and a failing dependency no longer fails scopes that `excludeConfigs` leaves out or the build when it lost a version conflict.
18
+
- Reachability scans that hit unresolved JVM dependencies now point out that ignoring them also needs `--reach-continue-on-install-errors`.
19
+
- A Gradle dependency whose variant is ambiguous in every configuration of its project now fails the run instead of quietly dropping out of the scan.
` Ambiguous variant — ${n} could not choose a variant, and the module resolved in no other configuration:`,
92
94
blocking: false,
93
95
notice: (n,depCount,configCount)=>
94
96
`Skipped ${depCount} dependency(ies) with ambiguous variant selection in ${configCount} configuration(s) — re-run with --verbose for ${n}'s messages.`,
0 commit comments