About a year ago, I wrote this blog post, where I discussed how to install and configure a z/OS-native GitLab Runner. At this time, this GitLab Runner was just freshly ported to the z/OS platform by the zopen community, and I gave it a try to setup my own GitLab pipelines using this Runner.
One major feedback was about the support of this Runner. Neither officially supported by GitLab nor IBM when it was introduced, many people thought it could not be used by customers in production environments because of this lack of support. Well, things have changed, and IBM and GitLab have announced their partnership in delivering an official, fully supported GitLab Runner for the z/OS environment. Recently announced, it is now available through IBM’s download platform known as Passport Advantage, as a licensed component.
Let’s open and see what’s inside the box!
The GitLab Runner package
Once downloaded from the IBM Passport Advantage site, you should end up with a PAX file, that you would need to decompress. This can be done with the pax -ppx command. Once unpacked, you will end up with a gitlab-runner subfolder which contains all the required material:
I typically recommend creating a technical user on z/OS, which will execute the GitLab Runner as an STC. In the above screenshot, this user is called GITLABR and it is designated as the owner of the files extracted from the PAX archive. This user should be given enough authority to perform the traditional steps of the CI/CD pipeline, which are the build with IBM Dependency-Based Build (DBB) and the deployment with IBM Wazi Deploy or IBM DevOps Deploy. It also means this technical user should have the rights to write to a given set of datasets, to support the build and the deployment phases of the pipeline.
The documentation provided at this location gives installation instructions and examples for a startup shell script and a JCL PROC to start the runner as an STC.
Registering and starting the GitLab Runner
Prior to executing the Runner as an STC, it must be configured and registered against the GitLab instance it will operate for. This can be done using the gitlab-runner register command line option, with an authentication token.
Once registered, a file called config.toml is created. If the registration was executed as root, this file is located in /etc/gitlab-runner, and should be moved to a .gitlab-runner subfolder in the HOME directory of the user that will run the STC (/u/gitlabr/.gitlab-runner, in my configuration). The config.toml file can be tailored to fit with your requirements.
During the registration process, it is advised to specify one (or multiple) tag to help identify this runner in pipeline configuration. I used the z/OS-native tag in my case.
Designing CI/CD pipeline definitions
Now the Runner is ready to pick up some work, we need to design a CI/CD pipeline to execute tasks on z/OS. Luckily, the IBM DevOps Acceleration Team is providing templates and samples in various forms.
The Common Backend Scripts is a collection of shell scripts that are simplifying the implementation of the main building blocks that we typically have in pipelines for z/OS applications. You can find them in this repository. Some configuration is required, so a read of the provided documentation is highly recommended!
The second type of materials you can use are the CI/CD pipeline templates, that you can found here. The pipeline template based on the z/OS-native GitLab Runner has very recently been released, to help GitLab users implement the traditional tasks defined by the Common Backend Scripts. You can find the GitLab CI pipeline definition to use with this z/OS-native GitLab Runner at this location. Both the CI/CD templates and the Common Backend Scripts are implementing the recommended Git Branching Model, described in the IBM Z DevOps Guide.
Conclusion
This new z/OS-native GitLab Runner is meant to simplify the architecture of your GitLab implementation. Instead of using a runner outside the Mainframe and deal with secure protocols like SSH or RSEAPI to connect to z/OS Unix System Services, this native Runner directly executes Shell commands on the z/OS platform. In terms of connectivity, the Runner connects to the GitLab server instance, either on-premise or on the Cloud, using an outbound connection, reducing the risk of exposing and opening inbound ports.
Using this native Runner also unlocks capabilities that were not easily accessible with complex architectures. For instance, it allows the attachment of artifacts to CI/CD pipeline executions or the pass of dependencies between steps in pipelines. To seamlessly integrate the z/OS platform into modern GitLab-based pipelines and benefit from all the capabilities offered by GitLab CI, the z/OS-native GitLab Runner is a must-have!