Improve error message for wrong-architecture container images (closes #38824)

Ashmit Sharmarequested to merge
4shm1td06/gitlab-runner:fix/issue-38824-improve-arch-error-message into main

What does this MR do?

Improves error reporting in the Kubernetes executor when a container image built for a different CPU architecture is used.

When a container image built for a different CPU architecture (e.g., ARM64 on AMD64, or vice versa) is used in a Kubernetes job, the container immediately crashes with exec format error and enters CrashLoopBackOff. Previously the runner silently ignored this state and eventually returned only a generic timed out waiting for pod to start error, leaving users with no actionable diagnostic information.

This MR adds CrashLoopBackOff detection to CheckTerminalContainerErrors in the Kubernetes pod watcher. When a container is in CrashLoopBackOff and its last termination message is available (e.g., exec format error), the error is now surfaced directly:

container "build" is in CrashLoopBackOff: back-off 10s: exec format error

This immediately tells the user that the image cannot execute on the node, strongly implying an architecture mismatch.

Additionally, the pod timeout error message now includes the last observed pod phase for better diagnostics.

Why was this MR needed?

Users running multi-architecture CI jobs on Kubernetes received unhelpful timeout errors with no indication that the image architecture was incompatible with the node.

What's the best way to test this MR?

  1. Create a Kubernetes pod using an image for a different architecture (e.g., --image=arm64v8/alpine on an amd64 node)
  2. Verify the runner reports: container "build" is in CrashLoopBackOff: back-off 10s: exec format error
  3. Run go test ./executors/kubernetes/internal/watchers/... to verify the new test cases pass

What are the relevant issue numbers?

Closes #38824 (closed)

Merge request reports