Closed antonio-tomac closed 2 years ago
@antonio-tomac Thank you for the detailed description. Could you create a small reproducer project containing the project structure you've described that suffers from the leaking layers issue?
@elefeint sure, here it is https://github.com/antonio-tomac/jib-layer-filter-file-leak-demo
I've noticed that style check failed due to *
import which my Intellij did without me noticing it so I reverted that change.
@antonio-tomac There is a minor checkstyle issue -- could you run ./gradlew goJF
to automatically fix it?
Kudos, SonarCloud Quality Gate passed!
Would you be interested in sending a pull request with the fix for the same issue in jib-layer-filter-extension-gradle?
Sure, but I haven't checked how gradle behaves, maybe gradle creates new instances of plugins per every module being built so it woudn't be an issue. But I'm just guessing it at this point.
I will try to reproduce it with gradle and if it suffers from issue, then I'll create PR for jib-layer-filter-extension-gradle
too, or just post about my findings.
I've tested it; same problem. Thank you!
jib-layer-filter-extension-maven:0.3.0
released.
I'm creating just PR without opening separate issue so I'll explain the issue here.
Consider having maven multi-module project:
Various layer filters are defined on
parent
so that bothservice-a
andservice-b
inherit configuration. Now, when doing maven reactor build in order:shared-lib
,service-a
,service-b
Final result is that:service-a
is build as expected, every filter did it's job and resources are sliced to layers as expectedservice-b
has everything that it should have + everything thatservice-a
had in it's corresponding layers.service-a
got "leaked" via JibLayerFilterExtension.newToLayers into subsequent module build ofservice-b
I'm not sure if this "leakage" is legit/desired in any scenario, if the answer is yes, then I would consider adding some configuration property (
boolean
) for this extension and then do clearing conditionally.