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

Support storing scancode-config.yml files in the scanned codebase #1236

Closed
pombredanne opened this issue May 16, 2024 · 3 comments
Closed

Support storing scancode-config.yml files in the scanned codebase #1236

pombredanne opened this issue May 16, 2024 · 3 comments
Assignees

Comments

@pombredanne
Copy link
Member

We need to allow storing scancode-config.yml files in the scanned codebase and used when running a pipeline.

There are many small edge cases to support:

  • when there multiple scancode-config.yml in multiple input archives (multiple "codebases")
  • when there are multiple scancode-config.yml inside an input archive
  • when there is a direct input scancode-config.yml and other scancode-config.yml in input archives

For now we should support only these cases:

  1. If there is a direct input scancode-config.yml file provided, it should be taken and have precedence and all other scancode-config.yml ignored.
  2. If there is a single archive input and it has a scancode-config.yml file at the root, it should be used
  3. If there are any other scancode-config.yml files elsewhere or more than one file in a single or multiple inputs, we should just report an error, and also in any other cases.

See also:

@pombredanne pombredanne changed the title Allow storing scancode-config.yml files in the scanned codebase Support storing scancode-config.yml files in the scanned codebase May 16, 2024
@pombredanne
Copy link
Member Author

And also update the doc accordingly

@pombredanne
Copy link
Member Author

@tdruez and I had a chat earlier today to discuss the topic of recursive extraction which is a config option.
If the scancode-config.yml is inside an input archive we would to extract it first to determine how we should extract. This is chicken and egg problem.

recursive extraction is the default and rarely to never makes sense to disable, therefore we are going remove recursive extraction as a scancode-config.yml option, and make this issue go away. recursive extraction will always take place.

Therefore we are going to have this revised and refined behavior:

  1. If there is a direct input scancode-config.yml file provided, it should have precedence and any other scancode-config.yml found in the codebase are ignored. Same if the config options were provided in the UI.
  2. Then if there is a single archive input and it has a scancode-config.yml file at the root, it should be used.
  3. Then if there are any other scancode-config.yml files elsewhere or more than one file in a single or multiple inputs, we should just report a warning stating that we ignore these config files.

tdruez added a commit that referenced this issue May 21, 2024
tdruez added a commit that referenced this issue May 21, 2024
tdruez added a commit that referenced this issue May 21, 2024
@tdruez
Copy link
Contributor

tdruez commented May 22, 2024

Implemented in #1243

@tdruez tdruez closed this as completed May 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants