Score 2774 traceability

[FScholPer]

-> see eclipse-score/score#2774

Frank Scholter Peres frank.scholter_peres@mercedes-benz.com, Mercedes-Benz Tech Innovation GmbH
Provider Information

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //src:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.4.2) and connecting to it...
INFO: Invocation ID: 61546472-b16d-4e49-8854-eb47c693626f
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
WARNING: Target pattern parsing failed.
ERROR: Skipping '//src:license-check': no such target '//src:license-check': target 'license-check' not declared in package 'src' defined by /home/runner/work/docs-as-code/docs-as-code/src/BUILD
ERROR: no such target '//src:license-check': target 'license-check' not declared in package 'src' defined by /home/runner/work/docs-as-code/docs-as-code/src/BUILD
INFO: Elapsed time: 4.966s
INFO: 0 processes.
ERROR: Build did NOT complete successfully
ERROR: Build failed. Not running target

[github-actions]

The created documentation from the pull request is available at: docu-html

[AlexanderLanin]

see discussion in #485

[FScholPer]

closed #485 @AlexanderLanin can you please check again?

[MaximilianSoerenPollak]

Some comments for things I noticed.

Will take another look after lunch.

Overall looks like genuine good work that we can build upon.

[MaximilianSoerenPollak]

Also a general thing.

If there is any 'substantial' or partial generation from AI please add the disclaimer in the header.
According to 'eclipse' something to the lines of this should be fine:

# ╓                                                          ╖
# ║ Some portions generated by <AI Model Name>               ║
# ╙                                                          ╜

Model name meaning like 'Gpt' or 'Copilot' or 'Claude' etc.

[FScholPer]

Also a general thing.

If there is any 'substantial' or partial generation from AI please add the disclaimer in the header. According to 'eclipse' something to the lines of this should be fine:

# ╓                                                          ╖
# ║ Some portions generated by <AI Model Name>               ║
# ╙                                                          ╜

Model name meaning like 'Gpt' or 'Copilot' or 'Claude' etc.

I will add. But we should think about using tools like https://github.com/git-ai-project/git-ai in general

[MaximilianSoerenPollak]

I will add. But we should think about using tools like https://github.com/git-ai-project/git-ai in general

Probably might be worth a look to see if we could use that. I can bring it up in infra.

[MaximilianSoerenPollak]

@FScholPer I would propose that I can take these Ideas & Proposals that you have made in this PR and re-implement them into Docs-As-Code so they fit a better architecturally and makes sense with how testcases etc. actually behave & are created inside the DaC frameworks that deal with it.

I fear it would be a lot more work to merge this PR and then rebuild it / change it quiet heavily later when we want to integrate it.

Do you think this would make sense and is a good way to move forward with this issue?

@AlexanderLanin @a-zw please also advice here in your opinion what would be a good approach.

[AlexanderLanin]

to me it sounds like we need to discuss the goals first, then how to achieve it. Thats the reason why this mixes extensions with custom executables and no-one really understands why and how it should look like.

[FScholPer]

to me it sounds like we need to discuss the goals first, then how to achieve it. Thats the reason why this mixes extensions with custom executables and no-one really understands why and how it should look like.

Goals for where 1. check linking of requirements to code/tests in ci 2. add dashboards in all modules. Or what goals do you have in mind?

[AlexanderLanin]

@FScholPer we've discussed this PR, unfortunately we missed you. So here is our interpretation. Let's have a call next week.

The goals here are:

• unify statistics/metrics across modules
• provide thresholds for acceptable values, especially for CI
• provide a dedicated executable / bazel target??

Here is an idea, which simplifies the design:

What do you think? (May be not self explanatory)
Do you want to give that a try?

[FScholPer]

@FScholPer we've discussed this PR, unfortunately we missed you. So here is our interpretation. Let's have a call next week.

The goals here are:

• unify statistics/metrics across modules
• provide thresholds for acceptable values, especially for CI
• provide a dedicated executable / bazel target??

Here is an idea, which simplifies the design:

What do you think? (May be not self explanatory) Do you want to give that a try?

I like the central json file to collect the results. I will check if this can be a way forward

[MaximilianSoerenPollak]

I like the central json file to collect the results. I will check if this can be a way forward

Let us know if there is any questions that arise or something that might be unclear, we gladly help answer them or clear up the confusion.
Looking forward to seeing your work.

[MaximilianSoerenPollak]

Overall this is not bad work, thank you for this.

Though there is some fundamental questions that I think need to be addressed.

This goes a bit beyond / adrift from what we imagined this should be.
I will try to make a bit clearer picture & describe it better so you can get a better idea of what exactly I mean.
But before I go into those points, let me restate that this overall shows that you thought about the issue and put in work to provide something that fulfils a need an a issue we have been trying to solve.
So do not feel discouraged by the comments and let me know if anything doesn't sound like it makes sense to you.

---

One point is that I do not see any reason that this should be standalone script able to execute standalone.
The reason we suggested the JSON was so that the sphinx extension during docs build can generate the metrics json and save it.
And then we can have a CLI script (in ci/cd workflows or wherever) that just reads this saved json and prints out the values & says yes, passed or no, not passed.

The reason to make this a Sphinx Extension is mainly due to simplicity of the code and speed, as well as information ability.
When it runs inside sphinx during the docs build you have access (depending on when you connect) to all information you potentially need to make your calculations.
You also have access to performance optimized functions to filter needs and other things that you then don't need to reimplement outside.
Converting it to a Sphinx-Extension can be a bit daunting, so let us know if we can help with that task at all or if any questions arise. I gladly help any way I can.

The last point that I'm unsure about is the touching / changing of the Source Code Linker.
The refactoring you did there seems to make sense to me in some ways, but I do not see any reason this should be in this PR at all, maybe you can enlighten me for the reason behind this.

---

A Picture, I hope this makes it a tiny bit clearer, please let me know if there are any questions.