Build a CI/CD pipeline with GitLab on Google Axion
Introduction
Create a Google Axion-based GitLab self-hosted runner
Automate the build and deployment of a multi-arch application with GitLab CI/CD
Next Steps

  Log an issue

  Fork and edit

  Discuss on Discord

About this Learning Path

Skill level:  Advanced
Reading time:  30 min
Last updated:  02 Jul 2026
Skill level:
  Advanced
Reading time:
  30 min
Last updated:
  02 Jul 2026
Author:Pranay Bakre, Arm
Arm IP:Neoverse
Tags: Containers and Virtualization Google Cloud Linux Kubernetes Docker GitLab
Author:
  • Pranay Bakre, Arm
Arm IP:
Neoverse
Tags:
Containers and Virtualization Google Cloud Linux Kubernetes Docker GitLab

Who is this for?

This is an advanced topic for DevOps professionals who are looking to build a CI/CD pipeline with GitLab on Google Axion based self-hosted GitLab runners.

What will you learn?

Upon completion of this Learning Path, you will be able to:

  • Create a Google Axion based GitLab self-hosted runner
  • Build a CI/CD pipeline with multi-architecture support
  • Build multi-architecture docker images using native GitLab runners on x86 and Arm
  • Automate the build and deployment of a multi-arch application with GitLab CI/CD

Prerequisites

Before starting, you will need the following:

Summary

AI-assisted

This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
You’ll create a Google Axion-based self-hosted GitLab Runner and wire it into a GitLab CI/CD pipeline that produces a multi-architecture container image. First, you’ll register the runner, choose an executor that fits your environment, and confirm it is available to your project. Then, you’ll configure the pipeline to build architecture-specific images on native runners for Arm and x86, push them to a container registry, and assemble a single multi-architecture image using the docker manifest approach. You’ll then trigger a pipeline, see jobs land on the intended runners, and verify that the published image advertises both arm64 and amd64 in its manifest.

Frequently asked questions

AI-assisted

These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
How do I know the Axion-based runner registered correctly?
Check the project or group’s Runners page in GitLab and confirm the runner shows as online. Run a test pipeline and verify the job log lists the expected runner and executor.
Which executor should I use for the self-hosted runner?
Choose the executor that matches how you want jobs to run in your environment. For example, use a Docker-based executor to run containerized jobs or a Kubernetes executor to schedule jobs on a cluster.
How are multi-architecture images built in this path?
You’ll use docker manifest to join separate architecture-specific images into a single multi-architecture image. You’ll build images for arm64 and amd64 on native runners, then create a manifest that references both.
What result should I expect after the manifest step completes?
You should have a single image tag that represents a manifest list containing entries for arm64 and amd64. When inspected in your registry, it shows both architectures under the same tag.
Can I mix GitLab-hosted and self-managed runners in the same pipeline?
Yes. You can use both types of runners and route specific jobs to the intended runner type through your CI configuration so architecture-specific jobs run on the correct machines.
Next