Unlocking Mainframe Modernization: Native s390x Support for GitHub Actions Runners

The world of enterprise IT is undergoing a rapid transformation, even in the most established sectors. Organizations running mission-critical workloads on IBM Z mainframes are increasingly adopting modern DevOps practices, including sophisticated CI/CD pipelines. A recent GitHub Community discussion, initiated by @panne3, brings a critical need to the forefront: official linux/s390x (IBM Z / LinuxONE) platform support for GitHub Actions Runner Controller (ARC) and runner binaries. This isn't just a technical request; it's a strategic imperative for enhancing productivity tools for software development and accelerating delivery in environments where reliability and performance are paramount.

The Critical Need for Native s390x Support

For dev teams, product managers, and CTOs overseeing operations on IBM Z, the demand for native s390x GitHub Actions self-hosted runners is undeniable. It's about more than just running code; it's about enabling a truly modern, efficient, and reliable CI/CD experience for the backbone of global commerce.

• Native Application Development: Enterprises in banking, insurance, and government sectors rely heavily on s390x-native applications. Building, testing, and validating these complex systems demand runners that operate directly on the target architecture, ensuring accuracy and performance from development to deployment.
• Eliminating Emulation Overhead: Current workarounds, which often involve cross-compilation or resource-intensive QEMU emulation, are notorious bottlenecks. They introduce significant delays, consume excessive compute resources, and can lead to unreliable test results, directly impacting software engineering OKRs related to delivery speed and quality. Native execution removes this friction, allowing teams to focus on innovation.
• Container-Native Workflows: The ability to deploy ARC on Kubernetes/OpenShift for s390x means these organizations can leverage the same ephemeral, auto-scaling runner infrastructure enjoyed by amd64/arm64 environments. This consistency streamlines operations, reduces management overhead, and aligns mainframe development with contemporary cloud-native practices.

Current Challenges and Fragile Workarounds

The absence of official linux/s390x support forces development teams into a maze of complex and often fragile workarounds. These stop-gap solutions, while demonstrating ingenuity, come with significant hidden costs and risks:

• Custom ARC Controller Builds: Teams must manually compile the ARC controller for linux/s390x from upstream source. While the Go codebase is s390x-compatible, this adds a maintenance burden, requiring internal teams to track upstream changes and rebuild constantly.
• Outdated Community Forks: Relying on community-maintained forks for s390x runner binaries, such as Gold-Bull/github-actions-runner, presents a major security and stability risk. These forks often lag significantly behind official releases, missing critical updates, bug fixes, and new features.
• Manual Helm Value Overrides: Deploying these custom builds requires intricate manual Helm value overrides, pointing to private registries. This complicates deployment, reduces portability, and increases the potential for configuration errors.

These workarounds divert valuable engineering resources from core product development to infrastructure maintenance, directly hindering overall productivity tools for software development.

The Path Forward: Official Support for s390x

The request from the community is clear and technically feasible, as highlighted by @panne3's meticulous breakdown. The core components are already largely compatible with s390x:

Short-Term Wins: Multi-Arch ARC Controller

The immediate goal is to integrate linux/s390x into the ARC controller's multi-platform container image build matrix. The controller, written in Go, compiles cleanly for s390x, and its base image (distroless) already supports the architecture. This change primarily involves a minimal adjustment to the existing CI/CD pipeline.

Medium-Term Vision: Official s390x Runner Binaries

Looking ahead, the next step is to publish official linux/s390x runner binaries alongside other architectures. This is now entirely viable, as the .NET runtime, on which the runner is built, has provided native s390x support since .NET 8.

Unmistakable Demand and Technical Readiness

The demand for this feature is not speculative; it's deeply rooted in the operational realities of major enterprises:

• The Gold-Bull/github-actions-runner community fork, despite its limitations, has been actively maintained since 2022, showcasing sustained user need.
• IBM Z / LinuxONE systems process over 70% of the world's transaction value. As these organizations increasingly adopt GitHub for source control and CI/CD, native runner support becomes indispensable.
• Multiple enterprises are independently custom-building ARC for s390x, a clear indicator of a widespread, unmet need that official support would consolidate and elevate.

Technically, the path is clear:

• ARC Controller (Go): Go supports GOARCH=s390x natively.
• Controller Base Image (distroless): Already multi-arch, including s390x.
• Runner (.NET): .NET 8+ fully supports linux-s390x.
• Runner Container Hooks: Go-based and compile for s390x.
• Helm Charts: Architecture-agnostic.

The community is even willing to contribute, with @panne3 offering pull requests and testing evidence from production OpenShift on IBM Z environments.

Building Community Momentum and Engaging GitHub

As @CristianOlivera1 rightly points out in the discussion, turning this feature request into a reality requires strategic engagement and collective action. For engineering managers and technical leaders, this is an opportunity to influence the development of critical tools for engineering managers and their teams.

1. Escalate within the GitHub Ecosystem

Beyond the community discussion, it’s crucial to open tracking issues in both the actions/actions-runner-controller and actions/runner repositories, linking directly back to the original discussion. This ensures visibility with product managers for GitHub Enterprise and ARC, who actively monitor these channels for architectural parity requests.

2. Address the Testing Challenge

One potential hurdle for the actions/runner team is the lack of GitHub-hosted s390x hardware for CI tests. Organizations running OpenShift on IBM Z could offer a Community-Maintained Remote Testing Endpoint / Hardware Resource. This collaborative approach, similar to how the Linux Kernel community supports niche architectures, would significantly de-risk the maintenance burden for GitHub, demonstrating a shared commitment to quality and stability.

3. Streamline Custom Image Generation (Until Official)

While awaiting official support, teams can improve their current workaround by automating multi-arch upstream builds using GitHub Actions with QEMU emulation for the initial compile phase. This approach, outlined by @CristianOlivera1, helps bypass outdated community forks and provides a more robust interim solution:

- 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

This snippet represents a significant improvement for teams currently struggling with manual processes, offering a more resilient approach to managing custom runner images.

Your Voice Matters: A Call to Action

If your enterprise or organization relies on GitHub Enterprise Server or Cloud alongside IBM Z Systems and needs native linux/s390x auto-scaling runners, now is the time to act. Upvote the original GitHub discussion and leave a comment detailing your use case. Demonstrating strong B2B enterprise demand is the most effective way to ensure this critical feature is prioritized on the official GitHub roadmap.

Conclusion

The official support for linux/s390x in GitHub Actions Runner Controller and runner binaries is more than just a technical upgrade; it's a strategic enabler for modernizing mainframe CI/CD, unlocking new levels of development velocity, and ensuring that critical enterprise workloads benefit from the best-in-class productivity tools for software development. By addressing this architectural gap, GitHub can empower a vast segment of the enterprise market to achieve their ambitious software engineering OKRs with greater efficiency, reliability, and innovation. The path is clear, the demand is evident, and the community is ready to collaborate.