You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2022/11/29 07:40:53 UTC

[GitHub] [camel-k] tobiasoort commented on pull request #3855: Added support for multi-arch building of Operator image

tobiasoort commented on PR #3855:
URL: https://github.com/apache/camel-k/pull/3855#issuecomment-1330209521

   > Why do we need to also make `make images` multi-arch even though we already have `make images-arch` which obviously builds images for multi-arch? 
   
   A couple of reasons! First of all, because 'it is the way'. Users expect dockerimages to be multi-arch and not ponder about what arch their system/cluster is on. Even the upstream containers like `ubi-quarkus-mandrel-builder-image` do this.
   
   Second, because it allows you to think about the _pipeline_ and not about specific arch builds. This also means that this multi-arch image would get pushed to dockerhub, 'business as usual'.
   
   Third: the multi-arch build depends on graalvm instead of quarkus (https://github.com/apache/camel-k/blob/3be0ab83ac6682c2412319a5778167d9dec08671/build/Dockerfile.arch#L16) because the right upstream image 'just for arm64' isnt there. This puts a split in the project dependencies and can cause weird issues downstream that are hard to reproduce.
   
   My suggestion would be to remove the 'images-arch' after this PR. It was a good way to get all the plumbing in place, but with official docker support for multi-arch and also upstream support from quarkus, we don't need that 'fork in the road' anymore.
   


-- 
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