build
build copied to clipboard
shipwright-io
Feature Discussion: Primary Support for Multi-Arch Builds
Feature Request
Provide a primary API/mechanism for users to declare that a build should be cross-compiled across multiple architectures, and combined into a manifest list.
Background
Some build strategies support multi-arch builds directly through cross-compilation (example - ko). Others could support multi arch builds directly through emulation (buildkit, buildah), or could use node selectors to run builds simultaneously and have Shipwright create the manifest list.
The okd community implemented a "multi-arch" build strategy - multi-arch native buildah. We could look at this as a real-world multi-arch build scenario to iterate on.
👋 hey @Adarsh-jaiss - happy to have help here!
As a first step, I think someone from the Shipwright community should read the okd build strategy linked above and map out the process in a HackMD or other collaborative document. I think translating their script code to plain language will help move the conversation forward.
Are you able to help get this started?
👋 hey @Adarsh-jaiss - happy to have help here!
As a first step, I think someone from the Shipwright community should read the okd build strategy linked above and map out the process in a HackMD or other collaborative document. I think translating their script code to plain language will help move the conversation forward.
Are you able to help get this started?
Sure, I would love to do this :)
Hey, @adambkaplan , I have summarized everything in 3 scopes, the 1st scope will give collaborators about the overview of what actually the file is doing. The 2nd scope is a deep dive into steps involved and 3rd scope is a code level deep dive,to understand what a specific line of code does. Please look into it and let me know the changes : Hack.md
This is a great write-up! I have cleaned up the formatting a bit and published your analysis here: https://hackmd.io/PeHcszOaR_6aekd0vfvOAg?view=
This is a great write-up! I have cleaned up the formatting a bit and published your analysis here: https://hackmd.io/PeHcszOaR_6aekd0vfvOAg?view=
Thanks @adambkaplan , Please let me know the next step for this now!
I put together my thoughts on multi-platform here: https://github.com/shipwright-io/community/issues/204#issuecomment-2107458651
Things that were mentioned but are not on the slides:
- We may want to let the user define the target platforms (like
spec.output.platforms) on a Build and BuildRun as first-class properties rather than strategy parameters - We need a build strategy author to tell us whether it can handle platforms itself or not. Mayby through usage of
${params.shp-output-platforms[@]}implicitly like we assume strategy-managed push when${params.shp-output-directory}is used ? - Shipwright Build internally is tight a lot on the fact that one BuildRun leads to exactly one TaskRun. Changing this will be a certain effort.
- The image merge logic is simple. The code that I had shown which even uses some of our existing internal libraries: main.go.zip
