add C0/C1 cov statistics

[antonkri]

📌 Description

This PR extends Module Verification Report with the functionality to collect code coverage data (after bazel coverage command), aggregate those data per component (:comp) and render this data in the final documentation using module verification report post-template. As the mapping between (sub-)components at the architectural level and source code folders is not clear, and this is needed to know which files belong to which component, module definition (:mod) was extended to provide this additional information. For more information see README.

🚨 Impact Analysis

• This change does not violate any tool requirements and is covered by existing tool requirements
• This change does not violate any design decisions
• Otherwise I have created a ticket for new tool qualification

✅ Checklist

• Added/updated documentation for new or changed features
• Added/updated tests to cover the changes
• Followed project coding standards and guidelines

[MaximilianSoerenPollak]

@antonkri There is no description or anything what this PR should acomplish, why it is needed or what it builds towards / upon.

It's a bit hard to review it without that knowledge.
we can review the code, but we still can not judge if this is something we want / should have in DaC.

Could you add this to the PR description please? Thanks.

[AlexanderLanin]

And how it achieves what it does, as its very difficult to infer that from reading the code.

[antonkri]

@MaximilianSoerenPollak , @AlexanderLanin done.

[AlexanderLanin]

@antonkri thanks that helps a lot!

review in progress (not a request to change anything yet!)

• review events where this registers
• find a better solution for source_roots
• update README
• use non zipped output from coverage tool
• warning on not found
• remove env reading from the extension (happens in parallel PRs for all extensions)
• ensure this works with score coverage tooling, e.g. set it as bazel dependency?
• all of this should run on comp and not on mod
• switch location to execpath
• according to description this currently doesnt work in bazel build mode

[MaximilianSoerenPollak]

First of all, thanks for the contribution, it seems like something that actually is a good idea (to add coverage to the documentation and implement it directly), so thanks a ton for that.

I have not gone through the code itself in detail as I think there is some fundamental thing to fix here first.
The first question to answer is if we want the coupling between component / feature / module source_code and the requirements. @AlexanderLanin also curious about your opinion here.
If we do want this then the following issues arise.

We first need a way to find a better way to correlate which sources belong to which component / feature / module etc.
The way you propose here in the PR via folders mentioned in the mod, at least to me, seems error prone and also is not a strong automatic coupling between the two.

I have not yet fully thought through the problem, so I don't have a better solution currently.
But I also fear if we don't think this through, that this shaky temporary setup will be used for a long time and we have trouble changing it in the future.
I would like to think through this, and discuss this internally with the other DaC maintainers to see what they may think about this and if there is good ideas.
And once we have those (how to couple the things) then I'm sure that you can take a lot of your implementation and adapt it to that new way of linking it and do it right from the start.
Or at least closer to a more permanent solution.

[AlexanderLanin]

We first need a way to find a better way to correlate which sources belong to which component / feature / module etc.

PR incoming 🤣