GitLab and the Mainframe

[dennis-behm]

Are you using GitLab as your DevOps platform? Today, there are really 3 options to drive actions on the Mainframe:

Option 1 -

You can use the use a SSH Runner/Executor (running on an x86) that automatically routes all jobs to the assigned mainframe environment. We have explained about the approach here: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102827

Option 2 -

Use a standard Shell Executor, that runs commands on the x86 environment , that then allows you to communicate with the mainframe via SSH, Zowe CLI. This pipeline template can be leveraged to implement the e2e scenario and leverages the Common Backend Scripts: https://github.com/IBM/dbb/blob/main/Templates/GitlabCIPipeline/README.md

Option 3 -

The zOS OpenTools team has ported the GitLab runner to USS, which allows you to start the runner there – you find the port here:
https://github.com/ZOSOpenTools/gitlab-runnerport. @M-DLB has recently blogged about it - find his tutorial at the IBM Community

Looking for a conclusion? Well .. each option obviously has Pros/Cons about the architecture, workflow and maintainability etc.

Here are my questions: Which option do you prefer? Where do you have the most experience with?

[v1gnesh]

To "modernize" effectively, Z should work like just another platform.
So option 3 should be the default, and the rest exception-based.
GL and IBM should work to formally add zOS-native runner as an experimental back-end.
Then, work can be done to improve it iteratively.

Right now, there's automation in the port's repo to attempt porting each new version/release automatically.
Once I have access to real iron through zopen, I can get back to this, to add automated tests & summarization too, so it's easier for the GL org to see/assess the health of this port.

[mhardin18]

Was not aware of the Gitlab runner port. This is good information.

[cybersorcerer]

Hi,
i completely agree with @v1gnesh the z/OS native gitlab runner is the way to go. The more parts are in a pipeline, the more parts can break! Secondly, the toolchain is very important! Young z/OS developers should focus on their job and not being forced to learn a new toolchain.

[M-DLB]

The only problem with solution 3 today (the z/OS native GitLab Runner) is that there is no support, from GitLab or IBM. This can be considered as experimental.
In that situation, I'm afraid this architecture can't be used in production, compared to the 2 others.
It would probably require a lot of asks and requests from the community, to make things change and have a formal support from someone.

[v1gnesh]

It's not possible for something to jump straight from day 0 to production.
"Experimental" is the first necessary step.

If we don't push for this, and instead "temporarily" settle for other options, we all know how temporary "temporary" solutions are.

Having a dependency on zowe (option 2) needlessly complicates things.

[mhardin18]

Having a dependency on zowe (option 2) needlessly complicates things.

Yeah, my one client on Gitlab, this would be a no go anyhow.

[dennis-behm]

Let me clarify this - the template that was published uses ZOWE CLI with RSEAPI server to show case this integration. However, you can easily change the command executions and switch to ssh .

[mhardin18]

Let me clarify this - the template that was published uses ZOWE CLI with RSEAPI server to show case this integration. However, you can easily change the command executions and switch to ssh .

This is interesting. Will have to look closer in the first of the year. This might enable said client to try and move forward with using the zOS gitlab runner. If it can be utilized via only ssh/scripts without the dependencies on zowe, then that would be further push to be able to reduce footprint by having a completely separate server/s that are just dedicated to the gitlab runner.

[mhardin18]

I should add... as I stated in another thread, there are issues with implementing things like this for an organization that is not familiar with USS. So that is another challenge.

[edge05]

I agree Option #3 is the way to go for one main reason. You can setup the Gitlab runner on z/OS as a started task with RACF non-logon UserID, and with outbound from z/OS to the Gitlab server. Much more secure than using SSH or other methods that require credentials.

Thank you Dennis.