Clarification / Best Practice required on how to handle multiple analyzer-result.yml files

[nikpete]

All,

We do have several use cases where an overarching project might consists of multiple services and product teams. Therefore, multiple analyzer-result.yml file will be submitted (let's say 10+) because the project is simply not able to generate ONE .yml file (i.e. technical restrictions, mono repo)

1. I would like to understand if there is an automatic way (best practice) how we can merge (in ORT) multiple yml. files into ONE?
2. The merge of multiple yml. files should also remove possibe duplicates (FOSS-componentes that are reused in all the repositories and are part of the different .yml files) because currently we are doing it manually which is to be honest a "pain in the ass".

Thanks, Nik

[sschuberth]

Sounds like a good fit a new helper-cli subcommand, or @fviernau?

[nikpete]

@sschuberth We are currently in the process of implementing this function. Once ready, we are going to create a pull request.

[sschuberth]

@porsche-rishisaxena, FYI, I can only assign @nikpete as he's the reporter (and none of you are project members, yet).

[porsche-rbieniek]

Porsche solution submitted as https://github.com/oss-review-toolkit/ort/pull/5315

[sschuberth]

Porsche solution submitted as #5315

Please associate issues with PRs by using one of the respective keywords in one of the commits in the PR instead of manually adding comments.

[mnonnenmacher]

For reference, if all code is located in Git repositories, a possible workaround for this issue is to create a new Git repository with all the other Git repositories as submodules. You can then use the new Git repository as input for the analyzer to get a single analyzer result with correct provenance information for all projects.

[sschuberth]

I would like to understand if there is an automatic way (best practice) how we can merge (in ORT) multiple yml. files into ONE?

I have a hunch that we're jumping to conclusions too quickly with implying that merging (analyzer) result files is the right approach.

Let's step back a bit and ask ourselves what we want to achieve. From re-reading @nikpete's OP my guess is that in the end only a single / combined report (i.e. attribution document) is needed. As attribution documents contain far less information than full-blown ORT result files, maybe the better approach is to not merge ORT result files beforehand at all, but to create a special reporter that can take multiple ORT result files and simply attributes to the union of all contained projects / packages in a single report?