Remove s390x/ppc64le arches in che container builds

[nickboldt]

Is your task related to a problem? Please describe

Today, we have builds that use docker buildx to create containers for the following arches:

• che-code: amd64 
• che-dashboard: amd64, arm64, ppc64le
• che-devfile-registry: amd64 
• che-docs: amd64 
• che-e2e: amd64 
• kubernetes-image-puller: amd64
• che-machine-exec: amd64, arm64, ppc64le
• che-operator: amd64, ppc64le
• che-plugin-registry: amd64 
• configbump: amd64, arm64, ppc64le, s390x (last built in 2021!)
• developer-images (UDI): amd64 

We also have other builds that are simple single arch:

• devworkspace-operator
• che-server
• che-theia

And we have chectl, which is built for many arches, including Mac and Windows:

• chectl: linux-arm,linux-x64,linux-s390x,linux-ppc64le,darwin-x64,darwin-arm64,win32-x64,win32-x86

Questions

1. Why are we building some components of Che for multiple arches? Is there a compelling reason to have a dashboard and server/factory, without the ability to launch a workspace running che-code?

2. Can you even install the Che operator without a compatible DevWorkspace operator for your arch? (I would be surprised if this is possible.)

3. Could we simplify the Che build infrastructure to use podman build or docker build instead of docker buildx, and focus on the single end to end deployment of Che on amd64?

For those worried that this means they can't use Windows to Mac to connect to their cluster, don't worry - I'm not suggesting we drop support of darwin or win32 arches.

I'm suggesting we drop container builds for arm64, s390x, and ppc64le, since there is no way to use those containers for a COMPLETE Che 7.60+ deployment with a vscode-based workspace.

Describe the proposed solution:

Plan after discussions with @l0rd:

• remove ppc64le and s390x

• keep arm64; add more arm64 builds for the containers that are only single-arch x64 today - see Add support for arm64 arch in che container builds #22007 and Set set provenance:false in workflows with docker/build-push-action (remove 0.9.1 pin in use docker/setup-buildx-action) #21954

Describe alternatives you've considered

Given we have tried to build Che components with Z and P without success (both using GH actions and Travis), those arches should definitely be dropped, as they are available downstream in Red Hat OpenShift Dev Spaces but the upstream images are not usable.

Support for arm64 could be explored if there's a need, but given today we only have arm images for dashboard, machine-exec, and configbump, that would be a long road to travel without a compelling reason to do so.

Additional context

Question also sent to https://www.eclipse.org/lists/che-dev/msg04456.html for consideration.

See also:

• Set set provenance:false in workflows with docker/build-push-action (remove 0.9.1 pin in use docker/setup-buildx-action) #21954 and
• Add support for arm64 arch in che container builds #22007

[nickboldt]

See also #21954

[nickboldt]

Revised plan after discussions with @l0rd:

• remove ppc64le and s390x
• keep arm64, and eventually add more arm64 builds for the containers that are only single-arch x64 today (eg., che-code): Add support for arm64 arch in che container builds #22007
• support using downstream dsc binary on arm64 https://issues.redhat.com/browse/CRW-3607

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.