One Pipeline, Three Operating Systems, Zero Excuses

The gap Toshaan pointed at in Lyon is closed.

Last week I wrote about porting Gitlab Runner to IBM i with IBM Bob. A five-year-old Gitlab issue closed over two evenings for about US$25 in Bobcoins. Toshaan's point at the Common Europe Congress was that no single CI/CD tool covers all three IBM Power operating systems. IBM i was the loud gap, so it got fixed first. But "all three" means Linux, AIX, and IBM i, and it's worth being precise about where each one actually stands.

Linux on Power

Linux on Power has been a solved problem for several years. Gitlab ships runner packages for ppc64le. You install them the same way you install a runner on x86. The standard procedure on gitlab.com works, and the repository has the packages. If you're running RHEL or SLES on Power, follow Gitlab's official instructions, and you're done in ten minutes.

IBM i

I wrote about IBM i Gitlab Runner last week.

What is missing?

"But you already did AIX"

Yes, I did. Several years ago I ported Gitlab Runner to AIX, published the binary, and moved on.

And then time did what time does. Gitlab Runner kept shipping releases. New features, new dependencies, a moving Go version requirement. My AIX port sat frozen in time at whatever upstream looked like on the day I built it many years ago. Every day is getting further from the current Gitlab Runner release. At some point, a binary that old stops being "a port" and starts being "an artifact."

So the AIX port needed redoing from the current upstream anyway. The question was how much work that would be a second time.

The IBM i port turned out to be the good start

Thanks to IBM Bob, I already had done most of work.

The IBM i work from last week left me with a patched tree that can be built for IBM i PASE. AIX and IBM i PASE share a lot of DNA. This shared DNA was exactly what made the IBM i port painful, because I spent most of my time finding the places where they diverge. Coming back the other direction, that same knowledge is an asset. I already knew which files upstream cares about the operating system in.

So I took the IBM i code tree as the base and worked back toward AIX.

And it went suspiciously well. The whole thing followed the same four steps as IBM i, in the same order:

1. Decide what actually has to change. Please sit down first and list what a runner on this platform is going to do. Which executors survive, which features are Linux-only and can’t be ported to AIX, what the service integration should look like. Doing this on paper before touching the code is the difference between a port and a very long argument with a compiler.

2. Add aix where the build constraints need it. Go's build tags are how upstream decides which platform-specific file gets compiled. A large chunk of the work in any port is simply finding every place where someone wrote a Unix list that stops at linux, darwin, freebsd and doesn't imagine anything past it. Tedious, mechanical, and it accounts for a surprising share of a port.

3. Strip the executors that don't belong on AIX. No containers, no Kubernetes, no VirtualBox, no Docker Machine. Trying to keep them compiling for AIX means dragging in half the container ecosystem for code paths nobody will ever execute. The shell executor is the one that matters here, and it's the one AIX admins or developers actually want.

4. Patch the packages that get AIX wrong. This is the step I thought I'd already paid for.

The step I didn't budget for

I assumed step 4 would be a formality this time. AIX has been supported GOOS for years. Unlike IBM i, which I had to teach Go about from scratch. Surely the ecosystem knows what AIX is by now?

Not entirely.

Gitlab Runner has grown new dependencies since my old port. Some of those modules have never met an AIX box in their lives. machineid had never heard of AIX at all. sys/unix knows what AIX is but got it wrong.

It is the same package that probably burned most of my Bobcoins on IBM i. On IBM i, sys/unix was wrong because IBM i isn't supported at all. On AIX it's wrong because AIX is supported, just not carefully. The constants are there, but some of them just don't match what the system actually uses. That's a nastier failure mode than "unsupported platform." It builds clean and then behaves strangely at runtime. You get to work backwards from the symptom to a constant somebody typed from the wrong header a decade ago.

That’s why porting to AIX in 2026 still takes evenings.

Not because AIX is hard, but because AIX is rarely tested.

It works

The current Gitlab Runner builds on AIX, registers against a Gitlab instance, picks up jobs, runs them through the shell executor, reports back, and stays up. Clone, build, test, artifacts. This is the ordinary pipeline stuff that behaves the way it behaves everywhere else.

Which means the set is complete. One CI/CD tool, one .gitlab-ci.yml syntax, one Gitlab instance, and runners on Linux on Power, on IBM i, and on AIX. If you have all three in your shop — and a lot of you do — you can now write one pipeline that brings a job to any of them.

Support the Power DevOps Newsletter!

If you like reading technical articles about IBM Power, AIX, and Linux on IBM Power, consider upgrading to the paid tier to show your support. As a paid subscriber, you not only get regular posts, but you will get additional posts with the full code and further explanations, access to the whole archive of the blog, and take part in our monthly calls where you can ask your questions and propose topics for future newsletters. Be an active member of our community!

Getting it running on AIX

1. Download the binary

Go to www.power-devops.com, click Downloads, and search for “gitlab runner”. Grab the AIX build for free, at the same place as everything else I publish there.

2. Get a runner token

Gitlab authenticates runners with a runner authentication token. Where you click depends on who's supposed to use the runner. For a single project, it lives in that project's Settings → CI/CD → Runners, behind a New project runner button. Group runners sit under Build → Runners in the group's own sidebar, and you need the Owner role to create one.

Either way, the rest is the same. Give it a description, and add a tag if you want to aim jobs at AIX specifically from your .gitlab-ci.yml. You get a token starting with glrt-. Copy it now. It's shown once, and the page doesn't care that you meant to come back to it.

3. Place the binary

What you download is a ZIP archive - gitlab-runner-aix-ppc64-19.2.1.zip, with the version matching the upstream release it was built from. Unpack it wherever you want the runner to live:

mkdir -p /opt/gitlab-runner
cd /opt/gitlab-runner
unzip /tmp/gitlab-runner-aix-ppc64-19.2.1.zip
chmod +x /opt/gitlab-runner/gitlab-runner-aix-ppc64

I use /opt/gitlab-runner and a dedicated gitlab user for my own tests. Use whatever directory suits your filesystem layout — just make sure the user running the runner can write to the build directory, and that the filesystem behind it has room for your repositories. Job workspaces, caches, and artifacts all land there, and a busy pipeline will fill a small /opt faster than you expect. A separate filesystem is not a bad idea.

4. Create the config

mkdir -p /etc/gitlab-runner

Create /etc/gitlab-runner/config.toml:

concurrent = 1
check_interval = 0
[session_server]
  session_timeout = 1800
[[runners]]
  name = "<your-gitlab-runner-name-here>"
  url = "<your-gitlab-instance-here>"
  token = "<your-glrt-token-here>"
  executor = "shell"
  shell = "bash"
  user = "gitlab"
  [runners.custom_build_dir]
  [runners.cache]

Set name and url to your own instance, paste your glrt- token, and set user to whichever account should own the build jobs. shell = "bash" assumes you have bash installed. On AIX 7.3 you already have it. If you prefer older releases, install it from the AIX Toolbox. If you'd rather stay with the system shell, shell = "ksh93" works too. Other shells like ksh or sh may or may not work.

5. Start it

For a first test, just run it in the foreground and watch:

/opt/gitlab-runner/gitlab-runner-aix-ppc64 run --working-directory /opt/gitlab-runner

Go back to GitLab, Settings → CI/CD → Runners, and confirm your runner shows up as online. Then fire a pipeline at it.

6. Make it survive a reboot

Once it works, add it into /etc/inittab.

mkitab "gitlabrunner:2:respawn:/opt/gitlab-runner/gitlab-runner-aix-ppc64 run --working-directory /opt/gitlab-runner >>/var/log/gitlab-runner.log 2>&1"

respawn gets you a restart if the process dies. Check /var/log/gitlab-runner.log after a reboot to confirm it came back up clean.

Your turn

Download it, point it at your GitLab, and run your real pipelines through it. Run the actual build you care about, with the compilers and the scripts and the twenty years of accumulated code in it. That’s where a port either holds up or doesn’t, and that’s the feedback that turns “works on my LPAR” into something other people can rely on.

If it breaks, tell me where. Comments are open.

Have fun with Gitlab Runner on AIX!

Andrey

Hi, I am Andrey Klyachkin, IBM Champion and IBM AIX Community Advocate. This means I don’t work for IBM. Over the last twenty years, I have worked with many different IBM Power customers all over the world, both on-premise and in the cloud. I specialize in automating IBM Power infrastructures, making them even more robust and agile. I co-authored several IBM Redbooks and IBM Power certifications. I am an active Red Hat Certified Engineer and Instructor.

Follow me on LinkedIn, Twitter and YouTube.

You can meet me at events like IBM TechXchange, the Common Europe Congress, and GSE Germany’s IBM Power Working Group sessions.