Deploy location inside actions.json based on branch.

[rishabkaushik]

I am doing development using git and Code for i. Our team has few developers and each has their own personal deploy location. This works when we compile in development libraries. Once that is tested we merge the changes in master branch and recompile the sources in production library, so that production sources are in sync and we can also transfer the sources for debugging to production, if needed.

The issue is that when compiling from master branch, we have a central deploy location for the team. Below is how it works:

1. Developer switches the repo to master
2. Changes deploy location to central location
3. Open source members and compile(custom commands)

This works but is cumbersome and developer may forget to switch deployment directories, and deploying feature changes directly to central deploy directory. This has happened. Is there a way to restrict feature branches to not be deployed to central deploy directory. Maybe a dictionary in actions.json to map/hardcode deploy location for master branch and user inputted for feature branch.

I understand this is very specific and limited application but if there is a workaround. I am thinking of restricting central deploy directory to a user and an automated process through githooks for compilation(using that specific user).

[thomprl]

I like the idea if I understand it correctly. Or the ability to add a Environment Custom Variable in the actions maybe?

[rishabkaushik]

Yes something like that. Something in actions should do it.

[arco400]

We have a similar (more or less) git workflow, and currently solve the branching for qa and production by using multiple vscode workspaces and multiple checkouts of the repo.

I like the idea too to have a manageable option for the deploy location, it would be nice if that could be done with a placeholder so that the deploy location can be managed through the .env file.

[arco400]

After watching Sanjula's latest "Beyond the Green Screen (Day 17) on LinkedIn I'm thinking if it would be more logical to have the deploy location added to the Profiles... Haven't used Profiles until now, but sounds like an option.

[sebjulliand]

I understand the need here. And the points raised in the discussion makes perfect sense.
However, that makes Code for i a participant in the build process and that is not, in my opinion, its purpose. It's meant to be an IDE, and it must allow developers to run compile commands and build processes. But the IDE itself should not be a part of the build process (in a sense that the build should be able to be run regardless of which tool starts it). Think of it as the separation of duty 😉

The working directory/deploy location in Code for i is meant to be a temporary, expendable location whose sole purpose is to have the source on the IFS to be able to run compilations and builds. It wasn't designed to be a "location that maters", if I can put it like that.

But I can think of a few solutions for that problem. The first that comes to my mind is having an additional step in the compilation/build action that will copy the source to the desired central location (i.e. VS Code -> IFS Work dir -> IFS Central location). Since the actions can take variables from profiles or .env files, having that central location defined there (or in another file, located in the repository, that can be read by the build to find the central location).

Actions can run multiple commands at once, so the first command could be "copy to the central location" (rsyncn that can be installed through yum, is an excellent shell tool to synchronize two locations very quickly - something like rsync -a -z --delete from_folder to_folder).

Using a tool like TOBi, depending on the size of your project, along with a shell script to do some preparation, could be a nice solution for your compile/build needs.

Those are just a few ideas.

Having the deploy location to be part of the profiles could be interesting, especially when the "shared profiles" will be implemented. But it's not coming very soon, so...

[rishabkaushik]

Thanks for the detailed explanation about this. It does make sense for Code for IBM i architecture.

The idea about copy to a IFS work directory and then sync with branch dependent location is nice, but that would add unnecessary complexity to the deployment, if there is an issue with let's say a production build because of a copy issue - it would be bad. Although with proper error handling that can be mitigated too, but I personally would not be in favor of it. But that is the only option for now, will see how do i implement it but do not really like the idea.

I explored TOBi when it was still in the early stage and was not suitable for our build process workflow. So dropped that.

Will be looking for a day when this will be part of shared profiles.

[rishabkshk]

Just a small update, since we were already running a helper devops automation service(express.js) I have made it possible to autocompile whenever a branch is merged into master from a central IFS location. This may help people who are in similar situation and this is all done on IBM i itself.

Below is how the compile looks like

fullCommand='export QIBM_CCSID=1208 ; liblist -a LIB1 LIB2 LIB3 LIB4 ; system -i "COMPILE OBJ(PRDLIB/PROGRAM) STMF('/builds/prod/release26.3/qsrcfil/PROGRAM.rpgle') OPTIONS(*EVENTF) BRANCH('master') VSCODE(N)" > '/temp/logs/PROGRAM_1783926697214.log' 2>&1'

Passing this to execSync

      execSync(fullCommand, {
        encoding: 'utf-8',
        timeout: 120000,
        shell: '/QOpenSys/usr/bin/qsh',
        stdio: 'pipe',
        maxBuffer: 10 * 1024 * 1024
      });

There are other complexities involved like ssh setup for the repo, finding the diff --name-only based on sha received from githooks triggered by a pull request merge, then pulling the latest changes from origin/master(maybe a hard reset if merge --ff-only is failed). Then at last compile programs retrieved from diff --name-only

Another option for us was to keep a trigger on a file where we log our merge into master events, and run a RPGLE/CLLE/QSH program to do this all, but with express.js it was fun.