fix: Improve report structure, fix template issue

[o-kopysov]

Pull Request

Description

Current PR contains improvement of the overall report layout and some template fixes.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Code cleanup/refactoring
• Documentation update
• This change requires a documentation update
• CI system update
• Test Coverage update

Testing

Local tests passed.

Checklist:

• My code follows the style guidelines of this project
• My code meets the required code coverage for lines (90% and above)
• My code meets the required code coverage for branches (80% and above)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 98.86364% with 1 line in your changes missing coverage. Please review.

Project coverage is 93.81%. Comparing base (7c0e849) to head (78e1dd4).

Files with missing lines	Patch %	Lines
...java/com/lpvs/entity/report/LPVSReportBuilder.java	98.86%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #633      +/-   ##
============================================
- Coverage     93.88%   93.81%   -0.08%     
- Complexity      623      628       +5     
============================================
  Files            52       52              
  Lines          2127     2150      +23     
  Branches        247      251       +4     
============================================
+ Hits           1997     2017      +20     
- Misses           56       58       +2     
- Partials         74       75       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[m-rudyk]

I'd recommend to split changes to '/test' and '/src'. For one commit - it is huge change.

[o-kopysov]

I'd recommend to split changes to '/test' and '/src'. For one commit - it is huge change.

Tests will fail in case of changes in src/
Why do we need PR with a failed build check?

[t-naumenko]

LGTM

[m-rudyk]

I'd recommend to split changes to '/test' and '/src'. For one commit - it is huge change.

Tests will fail in case of changes in src/ Why do we need PR with a failed build check?

test will fail if different PR's used. I mean - one commit for source another commit for tests.

[o-kopysov]

I'd recommend to split changes to '/test' and '/src'. For one commit - it is huge change.

Tests will fail in case of changes in src/ Why do we need PR with a failed build check?

test will fail if different PR's used. I mean - one commit for source another commit for tests.

What is the benefit of using such an approach? The reviewer has to review the final code, not the sequence of commits.

[m-rudyk]

I'd recommend to split changes to '/test' and '/src'. For one commit - it is huge change.

Tests will fail in case of changes in src/ Why do we need PR with a failed build check?

test will fail if different PR's used. I mean - one commit for source another commit for tests.

What is the benefit of using such an approach? The reviewer has to review the final code, not the sequence of commits.

it's just recommendation to simplify review. 140+ line in single commit including both source and test (I understand that it is fix) is huge.

[o-kopysov]

I'd recommend to split changes to '/test' and '/src'. For one commit - it is huge change.

Tests will fail in case of changes in src/ Why do we need PR with a failed build check?

test will fail if different PR's used. I mean - one commit for source another commit for tests.

What is the benefit of using such an approach? The reviewer has to review the final code, not the sequence of commits.

it's just recommendation to simplify review. 140+ line in single commit including both source and test (I understand that it is fix) is huge.

According to all recommendations that I found, the pull request size is recommended to be less than 200 lines.
Still, I don't understand why I need to split changes into several commits if the reviewer checks the final change, not the intermediate changes made in commits.

[m-rudyk]

I'd recommend to split changes to '/test' and '/src'. For one commit - it is huge change.

Tests will fail in case of changes in src/ Why do we need PR with a failed build check?

test will fail if different PR's used. I mean - one commit for source another commit for tests.

What is the benefit of using such an approach? The reviewer has to review the final code, not the sequence of commits.

it's just recommendation to simplify review. 140+ line in single commit including both source and test (I understand that it is fix) is huge.

According to all recommendations that I found, the pull request size is recommended to be less than 200 lines. Still, I don't understand why I need to split changes into several commits if the reviewer checks the final change, not the intermediate changes made in commits.

ok. Let's move this conversation out of this scope.