-
Notifications
You must be signed in to change notification settings - Fork 509
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated afterEach method signature #2882
Conversation
Eclipse JKube CI ReportStarted new GH workflow run for #2882 (2024-04-07T18:05:55Z) ⚙️ JKube E2E Tests (8590484870)
|
Quality Gate passedIssues Measures |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2882 +/- ##
=============================================
+ Coverage 59.36% 70.63% +11.27%
- Complexity 4586 5030 +444
=============================================
Files 500 486 -14
Lines 21211 19506 -1705
Branches 2830 2515 -315
=============================================
+ Hits 12591 13779 +1188
+ Misses 7370 4495 -2875
+ Partials 1250 1232 -18 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thx!
This PR addresses a minor code cleanliness issue in the ITGradleRunnerExtension.afterEach method within the JKube Gradle Plugin Integration Tests. Previously, the method signature unnecessarily declared throwing an Exception, despite no such exceptions being thrown within the method body or by its operations. This change simplifies the method signature by removing the throws Exception declaration, aligning it with best practices and enhancing code readability.
Fixes #2630
Type of Change
Bug fix (non-breaking change which fixes an issue)
Checklist
I have read the contributing guidelines
I signed-off my commit with a user that has signed the Eclipse Contributor Agreement
My code follows the style guidelines of this project
I Keep It Small and Simple: The smaller the PR is, the easier it is to review and have it merged
I use conventional commits in my commit messages
I have performed a self-review of my code
New and existing unit tests pass locally with my changes