You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "squakez (via GitHub)" <gi...@apache.org> on 2023/06/27 08:32:55 UTC

[GitHub] [camel-k] squakez commented on pull request #4517: Ref #4513: Allow to remote debug the Operator

squakez commented on PR #4517:
URL: https://github.com/apache/camel-k/pull/4517#issuecomment-1609042054

   > > Okey, I missed the target parameter. It could be good then, though, for maintenance reason I still think it would be easier to have separate Dockerfile, but I leave this to your judgment.
   > 
   > It is not clear to me what is the drawback of this approach in terms of maintenance, could you please clarify? What I can tell is that having a separate Dockerfile means that I will need to deal with 2 Docker images (original + debug) instead of only one since I won't be able to rely on stages anymore which makes the whole debugging process much more cumbersome
   
   It's a matter of organization (at least the way I prefer organizing the stuff). Having 2 separate configuration makes easy (again, to me) understanding what are the requirement for a "normal" build and which are the ones for a "debug" build. The way I proposed was to have 2 separate dockerfiles, being the debug dockerfile inheriting from the "normal" build. Then, I think we can have a `make images-debug` that takes care to do 2 builds, the normal `make images` and some docker build and push of the new debug image.
   
   Said that, it's my personal taste and opinion. I leave to your judgment if you want to follow up these advises or proceed with the PR the way it is.


-- 
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: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org