fix: rename version.properties to a unique name to avoid resource collisions - #415
Conversation
…lisions Signed-off-by: Antonio Fernandez Alhambra <antonio.alhambra@hivemq.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe Maven plugin configuration now writes generated Git properties to a framework-specific filename. ChangesGit properties output
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to The generated resource is renamed as intended to avoid shaded-JAR collisions, with no unresolved in-repository compatibility risk. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Companion to operator-framework/java-operator-sdk#3627, fixed on the operator SDK side by operator-framework/java-operator-sdk#3628:
kubernetes-webhooks-framework-coreandoperator-framework-coreboth generate a root-levelversion.properties, and the entries collide when the jars are merged into a shaded jar. Nothing in this repo reads the file, so this is only a rename of the generated resource.Note for release notes: anyone reading
version.propertiesdirectly from the kubernetes-webhooks-framework-core jar needs to switch to the new file name.Summary by CodeRabbit