Skip to content
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

Add missing values to resolved configuration #7453

Open
mnonnenmacher opened this issue Sep 4, 2023 · 6 comments
Open

Add missing values to resolved configuration #7453

mnonnenmacher opened this issue Sep 4, 2023 · 6 comments
Assignees
Labels
configuration About configuration topics enhancement Issues that are considered to be enhancements

Comments

@mnonnenmacher
Copy link
Member

The ResolvedConfiguration currently only stores package configuration, package curations, and resolutions. This is not enough to ensure that consistent reports can be created from the ORT result file.

Add the following properties:

  • Applied copyright garbage
  • License file patterns
  • Applied license classifications
  • Value of addAuthorsToCopyrights

Note that complete consistency cannot be achieved because some values like the license file archives cannot be included in the ORT result file.

Also see this comment: #6188 (comment)

@mnonnenmacher mnonnenmacher added enhancement Issues that are considered to be enhancements configuration About configuration topics labels Sep 4, 2023
@mnonnenmacher mnonnenmacher self-assigned this Sep 4, 2023
mnonnenmacher added a commit to oss-review-toolkit/ort-workbench that referenced this issue Sep 4, 2023
Add an option to use only the resolved configuration from the ORT result
file instead of the configuration from the local ORT config directory.
In the first iteration this only affects package configurations and
resolutions. Support for package curations will be added later.

Additional resolved configurations can be supported once implemented in
ORT [1].

The goal of this feature is to be able to use the ORT Workbench as a
replacement for a generated report. Currently this is not the case, as
the local configuration can be different to the one used be the ORT
tools which can lead to inconsistencies.

Note that currently not all screen update correctly when the setting is
changed, for example the package details screen needs to be reloaded to
show the changes and all filters are reset. This will be addressed in
later commits.

[1]: oss-review-toolkit/ort#7453

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@gmail.com>
@sschuberth
Copy link
Member

Applied copyright garbage

This file can historically be massive. Before including this into the resolved configuration, I'd like to re-evaluate whether the copyright garbage feature is still required at all. My hope would be that by now ScanCode has improved so much that practically no garbage is recognized as copyright statements at all, or that such garbage would implicitly be discarded by ORT as it cannot be associated to any nearby license.

@sschuberth
Copy link
Member

Value of addAuthorsToCopyrights

I believe it would be great if we could solve #4519 frist.

mnonnenmacher added a commit to oss-review-toolkit/ort-workbench that referenced this issue Sep 5, 2023
Add an option to use only the resolved configuration from the ORT result
file instead of the configuration from the local ORT config directory.
In the first iteration this only affects package configurations and
resolutions. Support for package curations will be added later.

Additional resolved configurations can be supported once implemented in
ORT [1].

The goal of this feature is to be able to use the ORT Workbench as a
replacement for a generated report. Currently this is not the case, as
the local configuration can be different to the one used by the ORT
tools which can lead to inconsistencies.

Note that currently not all screen update correctly when the setting is
changed, for example the package details screen needs to be reloaded to
show the changes and all filters are reset. This will be addressed in
later commits.

[1]: oss-review-toolkit/ort#7453

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@gmail.com>
@mnonnenmacher
Copy link
Member Author

Applied copyright garbage

This file can historically be massive. Before including this into the resolved configuration, I'd like to re-evaluate whether the copyright garbage feature is still required at all. My hope would be that by now ScanCode has improved so much that practically no garbage is recognized as copyright statements at all, or that such garbage would implicitly be discarded by ORT as it cannot be associated to any nearby license.

With "applied copyright garbage" I mean to only store the part which was actually used.

sschuberth pushed a commit to oss-review-toolkit/ort-workbench that referenced this issue Sep 5, 2023
Add an option to use only the resolved configuration from the ORT result
file instead of the configuration from the local ORT config directory.
In the first iteration this only affects package configurations and
resolutions. Support for package curations will be added later.

Additional resolved configurations can be supported once implemented in
ORT [1].

The goal of this feature is to be able to use the ORT Workbench as a
replacement for a generated report. Currently this is not the case, as
the local configuration can be different to the one used by the ORT
tools which can lead to inconsistencies.

Note that currently not all screen update correctly when the setting is
changed, for example the package details screen needs to be reloaded to
show the changes and all filters are reset. This will be addressed in
later commits.

[1]: oss-review-toolkit/ort#7453

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@gmail.com>
@sschuberth
Copy link
Member

The ResolvedConfiguration currently only stores package configuration

Should we also consider resolving all package configurations already at the analyzer stage? Currently, that happens only at the evaluator stage.

@mnonnenmacher
Copy link
Member Author

Should we also consider resolving all package configurations already at the analyzer stage? Currently, that happens only at the evaluator stage.

The analyzer does not know the resolved provenance, so that is not possible. The earliest point where this could be done would be the end of the scanner run.

@mnonnenmacher
Copy link
Member Author

mnonnenmacher commented May 2, 2024

Based on a discussion on Slack I have created the following proposal. If we agree that this should be implemented, it should probably be done before working on this issue and adding more data to the resolved configuration:

So far we have resolved the configuration at the latest possible time (e.g. the resolutions in the evaluator). This could result in inconsistencies between the exit codes of one tool and the results of another if they used different input, for example different resolutions.
IIRC the reason for that were some concerns regarding the orthw workflow which uses commands to re-resolve parts of the resolved configuration.
Instead, resolve the configuration at the earliest possible time, meaning each tool resolves the configuration for the data it created. This should make the logic easier to understand, for example because the reporter would not have to check anymore if the evaluator already resolved the resolutions. Also, this would mean that exit codes are always consistent with the resolved configuration in the created ORT result file. I could miss something, but that would mean:

  • Analyzer resolves package curations and resolutions for analyzer issues.
  • Scanner resolves package configurations and resolutions for scanner issues.
  • Advisor resolves vulnerability resolutions and resolutions for advisor issues.
  • Evaluator resolves rule violation resolutions.
  • Reporter resolves nothing.

The commands could have options to re-resolve parts of the resolved configuration if that is required for the orthw workflow (or there could be a separate command for that to simplify the others at the cost of having to run two commands).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
configuration About configuration topics enhancement Issues that are considered to be enhancements
Projects
None yet
Development

No branches or pull requests

2 participants