Add s390x cross-build libraries to builder container docker file about containerized-data-importer

[aglitke]

/assign @awels

[awels]

So if I understand the question correctly. KubeVirt has one builder per arch, where CDI has one builder, that installs packages based on the detected arch when running the build. And you want to know which version we want to do with CDI. Aka either switch to the KubeVirt model, or keep the CDI model, and install the packages on the fly if we detect s390x build in progress?

[cfilleke]

Good questions! Let me see if I can address that in a design document to attach to the issue today.

…

On Mon, Jun 3, 2024 at 9:15 AM Alexander Wels ***@***.***> wrote: So if I understand the question correctly. KubeVirt has one builder per arch, where CDI has one builder, that installs packages based on the detected arch when running the build. And you want to know which version we want to do with CDI. Aka either switch to the KubeVirt model, or keep the CDI model, and install the packages on the fly if we detect s390x build in progress? — Reply to this email directly, view it on GitHub <#3289 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYDVRINQBMAORXFF2RAUZDZFRT7HAVCNFSM6AAAAABIGLTDCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBVGE3TOMJZGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[cfilleke]

We're intending to:

• use option 'D' for the unit test phase of CI/CD implementation, where the runtime of the builder container is built in the github x86 test environment without Bazel (since there is no official binary of bazel build for s390x, and it's not needed for unit test anyway),
• use option 'C' when we progress to end-to-end testing there,
• use option 'A' for when we can build the builder container for s390x in our orange zone.

Option 'B' can only be enabled with getting an official Bazel build upstreamed for s390x in the bazel repo.

This issue addresses option 'C'.