search

shipwright-io / build

Shipwright - a framework for building container images on Kubernetes
https://shipwright.io
Apache License 2.0
626 stars 107 forks source link

Native multi-arch ClusterBuildStrategy #1634

Open aleskandro opened 1 week ago

aleskandro commented 1 week ago

Changes

This PR proposes a sample multi-arch native ClusterBuildStrategy. The ClusterBuildStrategy runs as a main orchestrator pod. It creates one "agent" job for each architecture requested by the Build. The agent jobs are responsible for building the container image and coordinate with the orchestrator pod via messages in FIFO pipes sent through the kubectl client.

The agent jobs run through the following coordination barriers:

  1. Wait for the assets to be uploaded (source code, pull secrets, etc...)
  2. Waiting for the image download to start
  3. Waiting for the image download to finish

The orchestrator pod:

  1. Create the agent jobs
  2. Upload the assets and signal the completion of the assets upload through a write to the FIFO pipe in each agent job
  3. Start the download of the oci archive
  4. Inform the agent jobs the download is completed (so that they can complete)
  5. Create a manifest-list and push it to the final registry.

The service account that runs the strategy must be able to create, list, get and watch Jobs and Pods. It also needs to be allowed the exec verb for pods.

Relates to #1119

/kind feature

Submitter Checklist

See the contributor guide for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

Add sample build strategy to orchestrate multi-arch container image builds. The service account executing this build strategy must have the ability to manage Jobs and Pods, as well as have the ability to exec into Pods.

/cc @adambkaplan

openshift-ci[bot] commented 1 week ago

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: adambkaplan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/shipwright-io/build/blob/main/OWNERS)~~ [adambkaplan] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment
SaschaSchwarze0 commented 1 week ago

🤔 I'll need to check if our test suite automatically runs a smoke test for each sample build strategy, or if that is something we need to add to the e2e test code directly.

Needs to be added specifically. Though, what would we test in GitHub actions, there is no way to create a KinD cluster with nodes of different architectures ...

aleskandro commented 1 week ago

🤔 I'll need to check if our test suite automatically runs a smoke test for each sample build strategy, or if that is something we need to add to the e2e test code directly.

Needs to be added specifically. Though, what would we test in GitHub actions, there is no way to create a KinD cluster with nodes of different architectures ...

I think for the matter of testing, it is good enough to build a single-arch image into a manifest-list, i.e., having only one element in the architectures list of the Build object. For sure some for loops will execute only once, but that should be ok?

What do you think?