-
Notifications
You must be signed in to change notification settings - Fork 480
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) : Add support for specifying initContainers via resource configuration (#1316) #1969
Conversation
Eclipse JKube CI ReportStarted new GH workflow run for #1969 (2023-02-08T12:48:12Z) ⚙️ JKube E2E Tests (4124097593)
|
Codecov Report
@@ Coverage Diff @@
## master #1969 +/- ##
============================================
+ Coverage 54.20% 55.54% +1.34%
- Complexity 4061 4263 +202
============================================
Files 480 481 +1
Lines 21067 21158 +91
Branches 2810 2834 +24
============================================
+ Hits 11420 11753 +333
+ Misses 8483 8202 -281
- Partials 1164 1203 +39
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
49e3b26
to
adfda2a
Compare
It's a bit strange. Sonar is reporting less than ~50% code coverage for ControllerResourceConfig, InitContainerConfig, MappingConfig, Arguments. But my IDE shows full test coverage 😕 Also, Sonar's code coverage (68.4%) does not seem to be similar to codecov (87.1%) |
adfda2a
to
c15a4c8
Compare
c15a4c8
to
c10a2be
Compare
needs conflict resolution |
c10a2be
to
de561b9
Compare
…urce configuration (eclipse-jkube#1316) + Deprecate all controller specific configuration options in ResourceConfig. Move all controller specific options to nested controller configuration. + Add controller(s) configuration option in ResourceConfig + Add initContainres configuraiton option in Controller configuration Signed-off-by: Rohan Kumar <rohaan@redhat.com>
…er configurtion Signed-off-by: Rohan Kumar <rohaan@redhat.com>
de561b9
to
bce34ee
Compare
public ControllerResourceConfig getController() { | ||
if (controller == null) { | ||
controller = createNewControllerConfig(); | ||
} | ||
return controller; | ||
} | ||
|
||
public List<ControllerResourceConfig> getControllers() { | ||
if (controllers == null || controllers.isEmpty()) { | ||
controllers = new ArrayList<>(); | ||
controllers.add(createNewControllerConfig()); | ||
} | ||
return controllers; | ||
} |
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.
Still reviewing the rest of the code
Not sure how we're dealing with the case where a user specifies both controller and controllers. Or the case where the user is specifying all of the other options.
IMHO getController
should remain private and access to controller information should only be allowed through the list (I think we should be doing something similar elsewhere).
Following are the cases I can gather:
- No controller, no controllers, no top-level controller settings:
We might want to init a dummy Controller object to avoid NPE, but this is not very elegant (getControllers
returns a single empty element) - No controller, no controllers, but top-level controller settings added:
getControllers
returns the result ofcreateNewControllerConfig
- Controller, no controllers, no top-level controller settings:
getControllers
returns a single element with the provided controller - No controller, controllers, no top-level controller settings
getControllers
returns the list of controllers - Controller, controllers, no top-level controller settings
getControllers
returns a merged list of controllers prepending the single controller - Controller or controllers, and top-level controller settings
getControllers
returns a merged list of controllers prepending the single.
top-level settings are ignored since they are deprecated (we might want to warn the user)
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.
After discussion
Remove the getControllers
method and just keep a single getController
that's in charge of retrieving or merging the legacy settings. i.e. we don't support multiple controllers.
If both (controller field and legacy fields are present), throw an exception with a helpful message for users to be able to safely migrate to the new config.
In case user is using legacy fields we log a debug message.
protected ControllerResourceConfig getControllerResourceConfig() { | ||
ResourceConfig resourceConfig = getConfiguration().getResource(); | ||
if (resourceConfig != null && resourceConfig.getController() != null) { | ||
return resourceConfig.getController(); | ||
} | ||
return ControllerResourceConfig.builder().build(); |
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.
Related to the previous comment, this method should call getControllers
If there is more than one controller, then we should warn the user.
…ntroller configuration Signed-off-by: Rohan Kumar <rohaan@redhat.com>
Signed-off-by: Marc Nuri <marc@marcnuri.com>
Follow up by documenting the new configuration fields and deprecating the legacy ones (Asciidoc) |
SonarCloud Quality Gate failed. |
Signed-off-by: Marc Nuri <marc@marcnuri.com>
Signed-off-by: Marc Nuri <marc@marcnuri.com>
Description
Fix #1316
org.eclipse.jkube.kit.common
packageResourceConfig. Move all controller specific options to nested controller configuration.
Documentation in #1970
Signed-off-by: Rohan Kumar rohaan@redhat.com
Type of change
test, version modification, documentation, etc.)
Checklist