Currently we don't have the option to publish a locally built docker image to a remote repository. You can do it using the docker CLI, but it would be nice to have some built in support.

Comment From: jayanth-iyer

Will there be any support to create K8s manifests automatically -skeletons - just using the mvn command - part of native build pack? Later the developer can just add the values and add and remove the keys from the yaml Does it even make sense to add this support? - want to understand

Comment From: jorgemoralespou

I don't think this use case should be something the spring-boot maven plugin should do. If it did, shouldn't it also need to include goals to deploy the application/image into different platforms? I think that users should stick to using multiple plugins rather than have one single plugin that does it all (not saying can't be provided by spring-boot). I saw that pattern in fabric8 maven plugin, and they had to slowly rollback and break that plugin into smaller ones, more single purposed. My 2 cents.

Comment From: davinkevin

This requirement/feature here is to be able to perform construction of the image directly into a registry, like jib does: https://github.com/GoogleContainerTools/jib

This, from my point of view, is a must-have because lot of company are using "Docker" CI but without "Docker in Docker", for security reasons. So currently, I see Jib, Kaniko everywhere… and they can't move to the spring boot plugin due to this docker requirement.

If the plugin can produce OCI image on file system, this could do the job partially, because we can use some tools like skopeo to do the "send" operation.

Comment From: jorgemoralespou

Then my bad, as there's no description in the issue, it might seem confusing for others as it's been for me. Maybe @philwebb can add the description so people understand better what they are voting/commenting on.

Comment From: philwebb

Sorry about that, I threw in the issue for my own reference and wasn't expecting any votes/comments. I've added a brief description.

Comment From: jorgemoralespou

I think then thy my comment is not outdated. https://github.com/spring-projects/spring-boot/issues/21001#issuecomment-686548109

Comment From: philwebb

@jorgemoralespou Can you elaborate a bit more on the problems we might face? I was originally thinking we might be able to shell out and call docker push. I think that's currently how jib deals with it.

Comment From: jorgemoralespou

Well, there's 2 sides: - Technical: You'd need to be able to support private and insecure registries, and you'd need to interface with Docker on Windows/Mac/Linux in different ways, so better to not shell out to docker but rather use a library that can deal with the pushing direclty. - Strategically: To me this is the real deal. If the spring-boot plugin start doing this, then what else? where's the line of what should be done in this plugin vs other plugins? To be honest, maven/gradle users know how to configure multiple plugins and how to call them, so what would be the difference of doing something like: mvn spring-boot:build-image spring-boot:push-image vs mvn spring-boot:build-image other-plugin:push-image.? I have in mind fabric8 times, now jKube and they struggle and broke it down as it was doing just way too much in a single place. Single purposed plugins that can be composed should be favoured in my opinion.

Comment From: philwebb

If there was a single purpose Maven and Gradle plugin that we could lean on and perhaps automatically configure (so you don't need to give the image tag) that would be an ideal option. The only one I found when looking previously was jib, and pushing isn't really a stand-alone feature. I also didn't have much luck finding a Java library that can talk to the registry, only Go and Python seem to exist. Perhaps RegistryClient from jib will be extracted into a library at some point.

Comment From: scottfrederick

Images can be tagged and pushed using the Docker daemon API, letting the daemon do all the work. We're in the process of adding support for authenticating to a registry from the daemon, which should suffice for pushing also.

We've generally tried to maintain parity between the Boot plugins and the pack CLI. pack supports pushing to a registry with a pack build --publish option. I don't think there's much risk of scope creep with just adding a comparable feature to the Boot plugins.

Comment From: theHilikus

the way the maven lifecycle is structured, it seems to me that publishing should be separate from building. the build-image goal attaches to the package phase, which makes sense, but not publishing. That should be done in the maven deploy phase. I haven't been able to find a way to only build in package and only publish in deploy. Am I missing something?

Comment From: scottfrederick

@theHilikus There is some discussion of this in #26187. We've tried to keep the focus of the Spring Boot build plugins on Cloud Native Buildpacks integration, and avoid adding features to cover the full lifecycle of an OCI image.

Comment From: theHilikus

I missed that ticket. thank you