Samsung / LPVS

License Pre-Validation Service analyzes which open source components and licenses are used in every patch. It returns the list of restricted licenses and the possibility of license violation on the comment with the exact code location and the open source component information.

https://samsung.github.io/LPVS/

MIT License

24 stars 26 forks source link

fix: Improve report structure, fix template issue #633

Closed o-kopysov closed 1 month ago

o-kopysov commented 1 month ago

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.

[X] 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:

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

codecov-commenter commented 1 month ago

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 :warning:

Additional details and impacted files

```diff @@ 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 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

o-kopysov commented 1 month ago

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?

m-rudyk commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.