knockknock10 commented on issue #6939: URL: https://github.com/apache/camel-k/issues/6939#issuecomment-6840468156
> Building on what [@knockknock10](https://github.com/knockknock10) mentioned, if we keep modelines, I think the separation between `build` and `deploy` introduces an interesting question around how configuration is handed off. > > Currently, modelines can contain both build-time configuration (dependencies, build traits) and deployment-time configuration (container traits, mounts, replicas). > > With separate commands, how would we handle that boundary? > > Should `kamel build` resolve the configuration and produce a deployment-ready manifest alongside the image? Or should `kamel deploy` still parse the original integration source to extract deployment-specific configuration? > > I wonder if having `build` produce a resolved declarative artifact would make the workflow cleaner, especially for CI/CD and GitOps use cases, without coupling deployment back to source parsing. > > Intrested in discussion just wanted to add my thoughts hallo @SnehaNprog Yeah Sneha, I think this makes sense. I had a look at how the current flow works, and I think we already have a good starting point for this. Currently, `kamel run` resolves the source and its options into an Integration resource, which holds both the build configuration and the deployment traits. Even `kamel deploy` doesn't need the original source again; it just moves an Integration from `Build Complete` to `Deploying`. So maybe we can keep that same idea with the new commands: `kamel build` resolves the modelines and creates the Integration resource with all the required configuration, and `kamel deploy` just triggers deployment using that resource. I don't think we necessarily need a separate manifest alongside the image, since the Integration resource itself can serve as that declarative artifact. The part I'd like to understand better is how we want to handle this for CI/CD and GitOps, especially when the build and deployment happen in different environments. We should make sure the resolved Integration can be carried forward without having to go back to the original source files. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
