Official linux/s390x support for Actions Runner Controller and Runner binaries

[panne3]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

GitHub Actions Community Discussion Draft

Post this at: https://github.com/orgs/community/discussions/new?category=actions

Category: Actions
Title: Feature Request: Official linux/s390x support for Actions Runner Controller and Runner binaries

---

Description

We are requesting official linux/s390x (IBM Z / LinuxONE) platform support for:

1. actions/actions-runner-controller — multi-arch controller container image builds
2. actions/runner — official s390x runner binary builds

Use Case

Organizations running workloads on IBM Z mainframes (s390x architecture) need GitHub Actions self-hosted runners that run natively on s390x to:

• Build and test s390x-native applications — Many enterprise workloads (banking, insurance, government) run on IBM Z. CI/CD pipelines need native s390x runners to build, test, and validate these applications.
• Avoid emulation overhead — Cross-compilation and QEMU emulation are slow and unreliable for complex test suites.
• Support container-native workflows — With ARC on Kubernetes/OpenShift for s390x, organizations can leverage the same ephemeral, auto-scaling runner infrastructure used on amd64/arm64.

Current Workarounds

Today, running ARC on s390x requires:

1. Custom-building the ARC controller for linux/s390x from upstream source (the Go codebase compiles cleanly for s390x)
2. Using a community fork (Gold-Bull/github-actions-runner) for s390x runner binaries — this fork is significantly behind upstream (last release: v3.314.1, corresponding to upstream v2.314.1 from March 2024)
3. Manual Helm value overrides pointing to custom-built images in private registries

What We're Asking For

Short term

• Add linux/s390x to the ARC controller's multi-platform container image build matrix. The controller is written in Go and the base image (distroless) supports s390x — this should be a minimal change to the CI/CD pipeline.

Medium term

• Publish official linux/s390x runner binaries in actions/runner releases. The .NET runtime (which the runner is built on) has supported s390x since .NET 8.

Evidence of Demand

• The Gold-Bull/github-actions-runner community fork has been providing experimental s390x builds since 2022, demonstrating sustained community demand.
• IBM Z / LinuxONE serves over 70% of the world's transaction value (banking, payments, government systems). These organizations increasingly adopt GitHub for source control and CI/CD.
• Multiple enterprises are independently custom-building ARC for s390x — official support would consolidate effort and improve quality.

Technical Feasibility

Component	s390x Readiness
ARC Controller (Go)	✅ Go supports GOARCH=s390x natively
Controller base image (distroless)	✅ Multi-arch including s390x
Runner (.NET)	✅ .NET 8+ supports linux-s390x
Runner container hooks	✅ Go-based, compiles for s390x
Helm charts	✅ Architecture-agnostic

Willing to Contribute

We are prepared to submit pull requests for adding s390x support to the controller image build pipeline. We have production experience running ARC on s390x (OpenShift on IBM Z) and can provide testing evidence.

Environment

• Platform: OpenShift 4.x on IBM Z (s390x)
• ARC Version tested: 0.14.2 (custom-built for s390x)
• Kubernetes: 1.28+

[CristianOlivera1]

This is an incredibly well-structured, comprehensive, and highly justified feature request. Expanding official architecture support to linux/s390x is a major requirement for financial institutions, insurance corporations, and government bodies modernizing their mainframe CI/CD pipelines via IBM Z and LinuxONE.

Since the core software ecosystem now fully aligns—.NET 8+ natively supporting linux-s390x and Go’s mature cross-compilation matrix—this architecture gap is no longer a language limitation, but a build pipeline orchestration task.

Here are a few technical recommendations and immediate actions to help build community momentum and catch the attention of the GitHub Actions product team:

1. Tag and Escalate within GitHub Ecosystem

To ensure this reaches the right maintainers, we need to make sure this gets referenced in the main upstream repositories.

• Once you post this here, it is highly recommended to open a tracking issue (or cross-link) in both actions/actions-runner-controller and actions/runner pointing directly to this discussion URL.
• Product managers for GitHub Enterprise and ARC monitor those issue trackers closely for architectural feature parity requests.

2. Addressing the Upstream .NET Runtime Challenge

While .NET 8+ officially supports linux-s390x, the main roadblock for the actions/runner team will likely be the structural testing matrix (GitHub-hosted runners do not natively run on s390x hardware to execute CI tests).

• Since you mentioned you run OpenShift on IBM Z, offering a Community-Maintained Remote Testing Endpoint / Hardware Resource (similar to how the Linux Kernel or Fedora/Debian testing infrastructure handles niche architectures) would immensely de-risk the maintenance burden for the GitHub team.

3. Immediate Workaround: Streamlining Custom Image Generation via Buildx

Until official support lands, communities facing this issue can bypass the abandoned community forks by automating their own multi-arch upstream builds using GitHub Actions with QEMU emulation for the initial compile phase:

- name: Set up QEMU
  uses: docker/setup-qemu-action@v3
  with:
    platforms: s390x

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3

- name: Build and push ARC Controller
  uses: docker/build-push-action@v6
  with:
    context: .
    platforms: linux/amd64,linux/s390x
    push: true
    tags: your-registry/actions-runner-controller:latest

Community Call to Action 👇

If your enterprise or organization is currently running GitHub Enterprise Server (GHES) or Cloud alongside IBM Z Systems and requires native s390x auto-scaling runners, please upvote 👍 this discussion and leave a comment with your use case. Showing strong B2B enterprise demand is the fastest way to get this prioritized on the official GitHub roadmap.

Thank you @panne3 for compiling such a meticulous technical breakdown!