The challenge was part of an Open Mainframe Project, where I was required to connect my local workstation to Github and then to mainframes using Zowe team configuration and to run a bash script with zowe commands in it. I started off by connecting my Windows laptop to Github, which was fairly simple. My understanding was that since I had installed Zowe CLI in my Windows CMD, it would automatically work in Github. My assumption was that since I had linked my laptop to Github, it would automatically share the Zowe CLI environment defined in my CMD and that I could run Zowe commands without much hassle. It was not to be. That is both a problem and also the beauty of Github. Though closed source, it is a host for open-source projects; you do what you want to do but nothing is offered on a platter! 

Another wrong notion I had was that, Github might be using some memory from my local machine to operate my part. So, I thought all I needed to do was to provide that path, where Zowe is installed. I did that first by using ‘zowe_path=$(which zowe)’ and then exclusively pointing it to my C drive location where Zowe was installed using ‘export ZOWE_PATH=<Zowe path in my C drive>’. This did not work either. My VS Code is connected to mainframes through Zowe. As a wild try, I copied zowe.config.json into github root to see if it picks mainframe connection details from there. That did not work too.

Finally, the sequence that worked for me was setup Java environment, set up Node.js environment and then install Zowe through ‘npm install zowe@Clli –global’. I still doubt whether –global had any impact whatsoever. I did provide my mainframe credentials, port and host, which I had stored in Secrets. In-line zowe commands started working in yaml. I could list datasets and members through in-line ‘zowe zos-files list data-set…’. At this point, I thought it was all done and I needed only to run the bash shell script. My understanding at this point was that the yaml provides environment to scripts that are called from it. But no, Shell scripts do not automatically inherit the environment that you configured or defined in yaml and from where you are running the script. Ok, I thought let me give mainframe credentials again including host and port. That did not help much. Provided node.js configuration path. Did not work. Export…probably works but did not work for me that time. Finally, I defined each of my mainframe credentials by using ZOWE_USERNAME, and the same for password, host and port in yaml and then defined the same set of variables using, ‘zowe config set…’ and by defining a temporary profile myZos and its variables in the bash shell script. It is only when I set this temporary profile myZos as my default profile, Zowe started firing and executing the commands. I used Github Secrets to hide mainframe configuration details, including port and host. Below are the screenshots of that workflow and the shell script.

Lessons learned:

In Github yaml, jobs and job steps operate quite unrelatedly to one another, save for the next step. It means the environments defined in a Github yaml are good only till the next step. You go a step beyond and it does not recognize what you defined two steps prior. This implies to me that when you install Zowe@Cli in github, it is just that some runtime environment is created, probably stored temporarily but never anything is installed in Github root, for it to refer back. That probably explains why you won’t find a trace of it two steps down the lane!

Additionally, the script that you run even in the subsequent step does not inherit the environment you defined in yaml. You need to do that again or link it back to Github yaml, probably by using Export. This was very difficult for me to comprehend initially. But the realization that I am operating on a web-based cloud and not on a local or remote machine, put things in a better perspective!