-
Notifications
You must be signed in to change notification settings - Fork 541
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
feat (jkube-kit/build/service/buildpacks) : Add BuildPackCliController (#2453) #2496
Conversation
Eclipse JKube CI ReportStarted new GH workflow run for #2496 (2024-01-25T13:06:07Z) ⚙️ JKube E2E Tests (7654819757)
|
b37abff
to
6ca424e
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2496 +/- ##
=============================================
+ Coverage 59.36% 70.32% +10.96%
- Complexity 4586 4962 +376
=============================================
Files 500 480 -20
Lines 21211 19308 -1903
Branches 2830 2494 -336
=============================================
+ Hits 12591 13579 +988
+ Misses 7370 4501 -2869
+ Partials 1250 1228 -22 ☔ View full report in Codecov by Sentry. |
6ca424e
to
5efd9f5
Compare
Sonar coverage is reduced due to BuildPackBuildOptions configuration class using Lombok annotations. |
BuildPackCommand buildPackCommand = new BuildPackCommand(kitLogger, pack, | ||
createBuildCommandArguments(buildOptions), | ||
l -> kitLogger.info("[[s]]%s", l)); | ||
executePackCommand(buildPackCommand, e -> { |
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.
Is there any reason we're doing this in such a weird way instead of using a regular try-catch block?
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.
Umm, as far as I remember it was done to avoid duplicating try catch block
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.
I have reverted to having try catch blocks in both methods
...s/src/main/java/org/eclipse/jkube/kit/service/buildpacks/controller/BuildPackController.java
Show resolved
Hide resolved
5efd9f5
to
55756ea
Compare
buildArgs.addAll(extractStringArg("--builder", buildOptions.getBuilderImage())); | ||
buildArgs.addAll(extractStringArg("--creation-time", buildOptions.getCreationTime())); |
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.
Sorry for nitpicking again, but I can't see either the increase in cognitive complexity for extractStringAsArg
either.
What's the case where flagValue will be blank?
If there's no such case, Arrays.asList proves to be more readable.
If the case is that any of those flag values might be optionally present, I'd try to be more explicit about this toArgsIfPresent
or something like that.
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.
Just the final nitpick, everything else seems fine.
55756ea
to
716ffb8
Compare
Needs rebase so that the java-8 check passes |
eclipse-jkube#2453) Signed-off-by: Rohan Kumar <rohaan@redhat.com>
716ffb8
to
def03ae
Compare
|
Description
Fixes #2453
Type of change
test, version modification, documentation, etc.)
Checklist