Feature Discussion: Primary Support for Multi-Arch Builds

[adambkaplan]

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.

[adambkaplan]

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.

[Adarsh-jaiss]

• Hey @adambkaplan , Please let me know, if i can assist you on this :)

[adambkaplan]

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

[Adarsh-jaiss]

👋 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 :)

[Adarsh-jaiss]

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

[adambkaplan]

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=

[Adarsh-jaiss]

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!

[SaschaSchwarze0]

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