Skip to content
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

Simple Dockerfile mode: provided Dockerfile is always skipped #197

Closed
devang-gaur opened this issue May 11, 2020 · 4 comments · Fixed by #208
Closed

Simple Dockerfile mode: provided Dockerfile is always skipped #197

devang-gaur opened this issue May 11, 2020 · 4 comments · Fixed by #208
Assignees
Milestone

Comments

@devang-gaur
Copy link
Contributor

Docs : https://www.eclipse.org/jkube/docs/kubernetes-maven-plugin#simple-dockerfile-build

Reference : fabric8io/fabric8-maven-plugin#1814

@rohanKanojia
Copy link
Member

I think this issue is due to generators already adding opinionated ImageConfiguration as resolvedImages and BuildConfiguration is never null
https://github.com/eclipse/jkube/blob/1d5cda2fe84ea61ca8880c6ca569183d3f275ea9/kubernetes-maven-plugin/plugin/src/main/java/org/eclipse/jkube/maven/plugin/mojo/build/AbstractDockerMojo.java#L820-L823

What should be the desired behavior here? In my opinion when simple Dockerfile is detected this ImageConfiguration should be replaced. But what if the user has provided XML configuration also for an image? What should be the precedence for configuration options? In my opinion, Dockerfile or resource fragments should be given most precedence, then XML configuration and then plugin's opinionated defaults.

@manusa
Copy link
Member

manusa commented May 21, 2020

When only a single image should be built with a Dockerfile no XML configuration is needed at all. All what need to be done is to place a Dockerfile into the top-level module directory, alongside to pom.xml. You can still configure global aspects in the plugin configuration, but as soon as you add an in the XML configuration, you need to configure also the build explicitly.

IMHO something which is configured should take precedence over the convention. This is also what's stated on the docs "...but as soon as you add an in the XML configuration...".

As a user, I may also face issues when something which I didn't configure takes precedence over what I'm expecting. e.g. User is completely unaware of the convention, so he places a Dockerfile in the module's root and configures XML to pick that Dockerfile but maybe add parts of the assembly from other directories, if the convention took precedence over the configured XML, the user wouldn't understand why the assembly was not working.

TL;DR Order of priorities:

  1. Dockerfile in root directory
  2. XML configuration
  3. Generator defaults

@rohanKanojia
Copy link
Member

Thanks for the feedback. Let me write a fix to check content of resolvedImages and replace it if from has one of the jkube opinionated images in it.

rohanKanojia added a commit to rohanKanojia/jkube that referenced this issue May 21, 2020
rohanKanojia added a commit to rohanKanojia/jkube that referenced this issue May 21, 2020
rohanKanojia added a commit to rohanKanojia/jkube that referenced this issue May 21, 2020
rohanKanojia added a commit to rohanKanojia/jkube that referenced this issue May 28, 2020
@manusa
Copy link
Member

manusa commented Jun 1, 2020

Blocked by #214

rohanKanojia added a commit to rohanKanojia/jkube that referenced this issue Jun 2, 2020
rohanKanojia added a commit to rohanKanojia/jkube that referenced this issue Jun 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants