-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove ReporterInput.resolutionProvider
#8026
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #8026 +/- ##
=========================================
Coverage 67.08% 67.08%
Complexity 2054 2054
=========================================
Files 357 357
Lines 17121 17121
Branches 2457 2457
=========================================
Hits 11486 11486
Misses 4613 4613
Partials 1022 1022
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
3e3979a
to
967a269
Compare
helper-cli/src/main/kotlin/commands/repoconfig/GenerateRuleViolationResolutionsCommand.kt
Outdated
Show resolved
Hide resolved
@@ -103,7 +103,7 @@ internal class RemoveEntriesCommand : CliktCommand( | |||
} | |||
|
|||
val ruleViolationResolutions = ortResult.getRuleViolations().let { ruleViolations -> | |||
ortResult.getResolutions().ruleViolations.filter { resolution -> | |||
ortResult.getRepositoryConfigResolutions().ruleViolations.filter { resolution -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commit message: Typo in "cofigurations".
but not the ones from the resolved configuration
I might be mistaken, but aren't resolutions from the repository configuration also baked into the resolved configuration?
If so, the quoted sentence should probably say "but not the other ones ...".
And if not, is it a mistake that resolutions from the repository configuration are not part of the resolved configuration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be mistaken, but aren't resolutions from the repository configuration also baked into the resolved configuration?
Yes, that's true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commit message: Typo in "cofigurations".
Typo is still there.
plugins/reporters/evaluated-model/src/main/kotlin/EvaluatedModelMapper.kt
Show resolved
Hide resolved
967a269
to
ba8739b
Compare
ba8739b
to
e3b751b
Compare
e3b751b
to
85db0af
Compare
model/src/main/kotlin/OrtResult.kt
Outdated
*/ | ||
@JsonIgnore | ||
fun getResolutions(): Resolutions = | ||
getRepositoryConfigResolutions().merge(resolvedConfiguration.resolutions.orEmpty()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What now confuses me here is: If as discussed here resolutions from the repository config are already part of the resolved configuration, why do they need to be merged here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I decided for this, as not all stages have the resolutions in the resolved configuration, e.g. like the analyzer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does merge
deduplicate resolutions?
IIRC only resolutions that actually match anything are added to the resolved configuration. Merging resolutions from the repository config would add those that don't match anything.
I decided for this, as not all stages have the resolutions in the resolved configuration, e.g. like the analyzer.
IMO if resolutions have not been resolved, it's fine to ignore those from the repository configuration. Because using them but ignoring those from the resolutions file is also inconsistent with what later steps that properly resolve resolutions will see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO if resolutions have not been resolved, it's fine to ignore those from the repository configuration.
I've changed it accordingly.
@@ -103,7 +103,7 @@ internal class RemoveEntriesCommand : CliktCommand( | |||
} | |||
|
|||
val ruleViolationResolutions = ortResult.getRuleViolations().let { ruleViolations -> | |||
ortResult.getResolutions().ruleViolations.filter { resolution -> | |||
ortResult.getRepositoryConfigResolutions().ruleViolations.filter { resolution -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commit message: Typo in "cofigurations".
Typo is still there.
model/src/main/kotlin/OrtResult.kt
Outdated
*/ | ||
@JsonIgnore | ||
fun getResolutions(): Resolutions = | ||
getRepositoryConfigResolutions().merge(resolvedConfiguration.resolutions.orEmpty()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does merge
deduplicate resolutions?
IIRC only resolutions that actually match anything are added to the resolved configuration. Merging resolutions from the repository config would add those that don't match anything.
I decided for this, as not all stages have the resolutions in the resolved configuration, e.g. like the analyzer.
IMO if resolutions have not been resolved, it's fine to ignore those from the repository configuration. Because using them but ignoring those from the resolutions file is also inconsistent with what later steps that properly resolve resolutions will see.
model/src/main/kotlin/OrtResult.kt
Outdated
@@ -272,7 +272,7 @@ data class OrtResult( | |||
.mapNotNull { (id, issues) -> issues.takeUnless { isExcluded(id) } } | |||
.flatten() | |||
.filter { issue -> | |||
issue.severity >= minSeverity && getRepositoryConfigResolutions().issues.none { it.matches(issue) } | |||
issue.severity >= minSeverity && getResolutions().issues.none { it.matches(issue) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Function docs need to be adapted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commit message: Typo in StatisticsCalculator
0cdf172
to
2ee3109
Compare
ortResult.getVulnerabilities(omitExcluded = true).values.flatten() | ||
.filterNot { resolutionProvider.isResolved(it) }.size | ||
private fun getOpenVulnerabilities(ortResult: OrtResult): Int = | ||
ortResult.getVulnerabilities(omitExcluded = true).values.flatten().size |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to also pass omitResolved = true
now in exchange for dropping .filterNot { resolutionProvider.isResolved(it) }
.
): IssueStatistics { | ||
val openIssues = ortResult.getOpenIssues(Severity.HINT).filterNot { resolutionProvider.isResolved(it) } | ||
private fun getOpenIssues(ortResult: OrtResult, ortConfig: OrtConfiguration): IssueStatistics { | ||
val openIssues = ortResult.getOpenIssues(Severity.HINT) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note (to myself as well): The signature of getOpenIssues()
is a bit inconsistent with getRuleViolations()
and getVulnerabilities()
in that it offers no omitResolved
parameter, but always filters for unresolved issues.
As such, the .filterNot { resolutionProvider.isResolved(it) }
call could have been dropped without a change of functionality independently of this commit / PR. Maybe this should be clarified in the commit message. Or do we even take the chance and align the API as part of this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As such, the .filterNot { resolutionProvider.isResolved(it) } call could have been dropped without a change of functionality independently of this commit / PR.
Can you help understanding why it would not change functionality?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getOpenIssues()
(as opposed to getIssues()
) is implemented like this:
ort/model/src/main/kotlin/OrtResult.kt
Lines 270 to 276 in 07f9efb
fun getOpenIssues(minSeverity: Severity = Severity.WARNING) = | |
getIssues() | |
.mapNotNull { (id, issues) -> issues.takeUnless { isExcluded(id) } } | |
.flatten() | |
.filter { issue -> | |
issue.severity >= minSeverity && getResolutions().issues.none { it.matches(issue) } | |
} |
so the getResolutions().issues.none { it.matches(issue) }
part already only keeps issues for which no resolution matches. Which means the .filterNot { resolutionProvider.isResolved(it) }
never was necessary here, if I'm not mistaken.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As such, the .filterNot { resolutionProvider.isResolved(it) } call could have been dropped without a change of functionality independently of this commit / PR. Maybe this should be clarified in the commit message. Or do we even take the chance and align the API as part of this PR?
However, this comment assumes that OrtResult
contains all resolutions. This wasn't true until my recent changed which changed the reporter command to ensure that. And that change was a preparation for this commit, so to me it makes sense to remove it in this commit. Does this make sense to you now as well ?
|
||
/** | ||
* Return a list of [RuleViolation]s for which no [RuleViolationResolution] is provided. | ||
*/ | ||
@Suppress("UNUSED") // This function is used in the templates. | ||
fun filterForUnresolvedRuleViolations(ruleViolation: List<RuleViolation>): List<RuleViolation> = | ||
ruleViolation.filterNot { input.resolutionProvider.isResolved(it) } | ||
ruleViolation.filterNot { input.ortResult.isResolved(it) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder whether we should instead simply drop these functions and tell reporter authors to call getRuleViolations(omitResolved = true)
. Similar below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be a breaking change, as we basically don't know who is making use of these.
I strongly prefer to, if at all, do this out of scope of this PR in a separate dedicated PR later on.
2023082
to
d3d7a18
Compare
d3d7a18
to
5784097
Compare
1299d6c
to
ee38e1e
Compare
ee38e1e
to
5bb980e
Compare
5bb980e
to
8d4859a
Compare
Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
The reporter command has been changed to ensure that all resolutions are included in the `OrtResult` before passing it around to the reporters. Reflect that also in this test asset. This was left-over by 10c0362. Signed-off-by: Frank Viernau <frank_viernau@epam.com>
Align all `reporter-test-input.yml` files to again have the same contents. Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
Prepare for the removal of `ReporterInput.resolutionProvider`. The change is non-functional because the reporter command ensures that all relevant resolutions are contained in the `OrtResult`. Signed-off-by: Frank Viernau <frank_viernau@epam.com>
Prepare for the removal of `ReporterInput.resolutionProvider`. The change is non-functional because the reporter command ensures that all relevant resolutions are contained in the `OrtResult`. Signed-off-by: Frank Viernau <frank_viernau@epam.com>
7390bf5
to
9877fb9
Compare
Prepare for the removal of `ReporterInput.resolutionProvider`. The change is non-functional because the reporter command ensures that all relevant resolutions are contained in the `OrtResult`. Signed-off-by: Frank Viernau <frank_viernau@epam.com>
Prepare for the removal of `ReporterInput.resolutionProvider`. The change is non-functional because the reporter command ensures that all relevant resolutions are contained in the `OrtResult`. Signed-off-by: Frank Viernau <frank_viernau@epam.com>
The reporter command ensures that all resolutions are contained in the ORT result. So, the resolution provider is not necessary anymore. Signed-off-by: Frank Viernau <frank_viernau@epam.com>
As `OrtResult` meanwhile has all the functions of `ResolutionProvider`, make it implement that interface to document that. Signed-off-by: Frank Viernau <frank_viernau@epam.com>
Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
9877fb9
to
ab50952
Compare
As of the addition of
OrtResult.resolvedConfiguration
, the ORT result is self-contained WRT to package configurations,resolutions and curations. So, in theory the
OrtResult
can be passed to each respectiveReporter
withoutany accompanying provider, e.g.
ResolutionProvider
,CurationProvider
as you name it. This would be less complicated to handle: e.g. make theReporterCommand
first include all the data inOrtResult
and then pass around theOrtResult
to the reporters.If you look at the functions
OrtResult.getOpenIssues()
orOrtResult.getResolutions()
, these consider only resolutions from the repository configuration, but not the ones from the resolved configuration. So, the result of these functions can normally only be used by further processing it with some matching against data from aResolutionProvider
. This inconvenience would be removed if just all data was included inOrtResult
and actually also used by its member functions.This PR implements this only for the resolution provider.
An analog PR should be done for package configurations, which would allow to implement filtering issues by
affectedPath
/ path excludes withinOrtResult.getIssues()
.Part of #7921.