I'd like to rework quarks:deploy to be similar to what I did for quarkus:run in my dev branch [1] as I am implementing my own deploy for Azure Functions (and later AWS lambda).
From CLI, it looks like the kubernates flavors never run together: i.e. you wouldn't deploy them at the same time.
So I'd like to do the following:* Have a "quarkus.deploy.target" like I do for quarkus run. If there are more than one deployment steps, then the appdev must choose one. (CLI does this). I will refactor a bunch of code here to clean up the kubernates flavor deploy steps.
* Why does quarkus:deploy run in package phase? I would imagine you'd want it to be separate and not have to rebuild before deploy, i.e. if you are changing deployment config and don't want to have to rebuild.
--Bill BurkeRed Hat
--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjRpyN5q_XTmDJH2fKu8n6sPWyU%2BT4OdGkqM_xQnvMW4Aw%40mail.gmail.com.
This seems to be the entry point for all kube deploy actionsIt also seems that deploy is hard wired into builds (and kubernetes is the only extension that takes advantage of this)Makes me think I can't unwind this stuff and separate deploy from package as it may break backward compatibility for those that have explicitly wired in kubernetes.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjTyAYiTQLeeq0-kUdvdunVW_Ajz9N7JzC7p5P-UamatVw%40mail.gmail.com.
On Thu, 30 Mar 2023 at 03:17, William Burke <bbu...@redhat.com> wrote:This seems to be the entry point for all kube deploy actionsIt also seems that deploy is hard wired into builds (and kubernetes is the only extension that takes advantage of this)Makes me think I can't unwind this stuff and separate deploy from package as it may break backward compatibility for those that have explicitly wired in kubernetes.I think it should still be possible, but at the moment it is a big limitation that deploy is tied to the build.If you want to separate it out we will probably need to create some kind of deployment manifest that is generated by the build, that contains all the information needed for a standalone deployment step.
Hmmm, why is it so much more complicated for K8s and a manifest is needed? For azure functions, I have all the metadata needed (i.e. whether its a uber or thin jar, directory paths, etc.). I just pull in the build step objects I need (like OutputTargetBuildItem, and config). Isn't it just a matter of unwinding the container/k8s deployments steps to not be dependent on build step objects generated only in a build?
On Fri, 31 Mar 2023 at 05:25, Ioannis Canellos <ioc...@gmail.com> wrote:On Thu, Mar 30, 2023 at 1:27 PM William Burke <bbu...@redhat.com> wrote:Hmmm, why is it so much more complicated for K8s and a manifest is needed? For azure functions, I have all the metadata needed (i.e. whether its a uber or thin jar, directory paths, etc.). I just pull in the build step objects I need (like OutputTargetBuildItem, and config). Isn't it just a matter of unwinding the container/k8s deployments steps to not be dependent on build step objects generated only in a build?I am not 100% sure I get what the problem is here. Can't we just perform a custom build that requests the DeploymentResultBuildItem?If you did that with the current code-base it would rebuild everything again. I think even if you fed in ArtifactResultBuildItem instances as inputs because it is a MultiBuildItem it may still attempt to generate the rest of them, but I am not 100% sure of that, so maybe doing a custom build where you feed in BuildItems that point to the previously created artifacts might work.
On Thu, 30 Mar 2023 at 03:17, William Burke <bbu...@redhat.com> wrote:This seems to be the entry point for all kube deploy actionsIt also seems that deploy is hard wired into builds (and kubernetes is the only extension that takes advantage of this)Makes me think I can't unwind this stuff and separate deploy from package as it may break backward compatibility for those that have explicitly wired in kubernetes.I think it should still be possible, but at the moment it is a big limitation that deploy is tied to the build.