-
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
fix (jkube-kit/enricher) : WellKnownLabelEnricher also considers labels added via resource configuration #2587
fix (jkube-kit/enricher) : WellKnownLabelEnricher also considers labels added via resource configuration #2587
Conversation
Eclipse JKube CI ReportStarted new GH workflow run for #2587 (2024-02-05T10:42:25Z) ⚙️ JKube E2E Tests (7783086545)
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2587 +/- ##
=============================================
+ Coverage 59.36% 70.38% +11.01%
- Complexity 4586 4969 +383
=============================================
Files 500 480 -20
Lines 21211 19342 -1869
Branches 2830 2496 -334
=============================================
+ Hits 12591 13613 +1022
+ Misses 7370 4501 -2869
+ Partials 1250 1228 -22 ☔ View full report in Codecov by Sentry. |
dc23e62
to
a08fbcd
Compare
private Map<String, String> convertLabelsToMap(Supplier<Properties> labelSupplier) { | ||
Properties labelsAsProps = labelSupplier.get(); | ||
Map<String, String> labels = new HashMap<>(); | ||
if (labelsAsProps != null) { | ||
for (Map.Entry<Object, Object> e : labelsAsProps.entrySet()) { | ||
String key = (String) e.getKey(); | ||
String value = (String) e.getValue(); | ||
labels.put(key, value); | ||
} | ||
} | ||
return labels; | ||
} | ||
|
||
private Map<String, String> mergedSelectors(Map<String, String> originalSelectors, List<Supplier<Properties>> labelSupplierList) { | ||
Map<String, String> labelsFromResourceConfig = extractLabelsConfiguredViaResourceConfig(labelSupplierList); | ||
MapUtil.mergeIfAbsent(originalSelectors, createLabels(true, labelsFromResourceConfig)); | ||
return originalSelectors; | ||
} |
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.
Have you checked PropertiesUtil and MapUtil to see if some of the provided methods can be reused?
I'm kind of sure we can easily remove the convertLabelsToMap method and replace it with toMap(labelSupplier.get()), but we can very likely simplify more
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.
mergeMaps + toMap should really allow you to remove extractLabelsConfiguredViaResourceConfig + convertLabelsToMap and make it more clear in the calling methods.
I'm not sure if we're being clear about precedence either.
Also MapUtil.mergeMaps can be changed to MapUtil.mergeMaps(Map<K, V> maps...)
to be able to support a variable number of maps
a08fbcd
to
ff384ed
Compare
private Map<String, String> mergedSelectors(Map<String, String> originalSelectors) { | ||
MapUtil.mergeIfAbsent(originalSelectors, createLabels(true)); | ||
@SuppressWarnings("unchecked") | ||
private Map<String, String> mergedSelectors(Map<String, String> originalSelectors, List<Supplier<Properties>> labelSupplierList) { |
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'm still not sure why we're using Supplier here instead of providing the properties themselves. Is there any reason to make this lazy?
* @param <K> first type | ||
* @param <V> second type |
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.
Should be changed.
We might also want to comment on the precedence of the maps
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.
Are you referring to @param
entries for types?
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.
yes
ff384ed
to
bebe736
Compare
…ls added via resource configuration While adding labels and selectors to a resource, WellKnownLabelEnricher and ProjectLabelEnricher would give precedence to label configured via resource label XML/Groovy DSL configuration. This precedence would depend on the type of resource label configuration used. If `all` has been provided in configuration, this means precedence would be given for all resources. However, if some specific resource label configuration is used; precedence would only be given for that specific resource Signed-off-by: Rohan Kumar <rohaan@redhat.com>
bebe736
to
6e214f2
Compare
Signed-off-by: Marc Nuri <marc@marcnuri.com>
2fc40ac
to
420c2ec
Compare
|
Description
Fix #1700
While adding labels and selectors to a resource, WellKnownLabelEnricher and ProjectLabelEnricher would give precedence to label configured via resource label XML/Groovy DSL configuration.
This precedence would depend on the type of resource label configuration used. If
all
has been provided in configuration, this means precedence would be given for all resources. However, if some specific resource label configuration is used; precedence would only be given for that specific resourceMap<String, String> labelsViaResourceConfig
in AbstractLabelEnricher.createLabels to accommodate labels configured via resource configuration.labelsViaResourceConfig
would override default opinionated or enricher configuration settings.createLabels
, various resource visitors would also pass their specific resource label configuration option so that that can be checked while creating opinonated labelsType of change
test, version modification, documentation, etc.)
Checklist