placeholderfeatureplaceholdersliderplaceholderthumb

ILE CiCd - Part 3 - Configuring BOB

by John Weirich

This post is continued from ILE CiCd Pipeline with Gitlab - Part 2 - Local Development Setup.

In the previous post, we created some source on our local PC, and set up the Code4i Actions that allow us to deploy the source and compile it on our IBM i partition. Some of the source, however, does not have a built in action for compiling, so we must use an additional tool, called Bob. Bob will also be used as our build tool in our CiCd pipeline.

Introducing the Better Object Builder - Bob!

Better Object Builder, or Bob, is a tool for building your programs, etc. It builds make files on the fly depending on which objects need to be built, while handling dependent objects as well.

Bob is installed on the IBM i through the ACS Open Source Management tool, or through YUM RPM package manager. Installation instructions are here.

Once installed, Bob will allow us to build all IBM i objects using source stored on our local PC. This includes the ability to build objects using pseudo source. Pseudo source is powerful, in that it allows you to create objects from CL commands or DDL source, that normally you would have to create from a 5250 command line or DB2 SQL prompt. Example objects you can create with pseudo source include Data Areas, Data Queues, DDL Tables and Indexes.

Bob requires a bit of project metadata in order to get it going, so lets begin by discussing the metadata files that are required.

iproj.json

Create a file named iproj.json at the root of the project. This file contains information about your project. Here is a sample to get you started:

/iproj.json

 {
    "version": "0.0.1",
    "description": "My First IBM i Project",
    "objlib": "&objlib",
    "curlib": "&objlib",
    "includePath": [""],
    "preUsrlibl": "",
    "postUsrlibl": "",
    "setIBMiEnvCmd": [""],
    "repository" : "https://gitlab.com/JDubbTX/my-first-ibm-i-project"
}

🔥 The important thing in this file is the objlib, which tells Bob where to put the compiled objects that it builds. We use an environmental variable for this that is set in our .env file discussed below. The other options are not mandatory, but you can read more about them in the Bob documentation here.


Setting Code4i environmental variables

The following file allows us to set the &objlib environmental variable that is used in iproj.json.

Code4i allows us to specify project environmental variables in a special file named .env. Create this file at the root of your project with contents similar to what is shown below, putting your target object library - the library where objects will be built - instead of MYOBJLIB. In my case, one of the two libraries assigned to me with my PUB400.COM account was JWEIRICH1, so I used that.

/.env at the project root

objlib=MYOBJLIB

Another thing to note, is that the .env file is used for setting environmental variables that are used with build actions in the Code4i extension, but not with Gitlab-Ci, our chosen ci-cd solution. In Gitlab Ci, we will use a built-in Ci variables to set the the same value.


Rules.mk - Rules for building with Bob

Bob relies on several Rules.mk files so that you can specify how objects are to be built. You will need a Rules.mk file at the root of your project that contains the name of all the source files. You will also need one in each source directory that associates the source files in that directory with the name and object type of the object being built.

/Rules.mk at the project root

SUBDIRS = QCLLESRC QDTASRC QDDSSRC QRPGLESRC

This is the Rules.mk file at the project root. It specifies each subdirectory that Bob will look in for source files to build into objects.

/QCLLESRC/Rules.mk

MYCL.PGM: MYCL.PGM.CLLE

The MYCL program object will be built from the MYCL.PGM.CLLE source file.

/QDTASRC/Rules.mk

MYDTAQ.DTAARA: MYDTAQ.DTAARA

The MYDTAQ data queue object object will be built from the MYDTAQ.DTAARA source file.

💡 NOTE: As mentioned in our last post, Bob doesn’t currently have a recipe for data queue objects, so we are utilizing the data area recipe for this purpose. This has the unfortunate side effect that Bob will rebuild our dtaq object unnecessarily some times.

/QDDSSRC/Rules.mk

MYDSPF.FILE: MYDSPF.DSPF

The MYDSPF file object object will be built from the MYDSPF.DSPF source file.

/QRPGLESRC/Rules.mk

MYRPGLE.PGM: MYRPGLE.PGM.RPGLE MYDSPF.FILE

The MYRPGLE program object will be built from the MYRPGLE.PGM.RPGLE source file.

💡 NOTE: For the MYRPGLE program rule, we included MYDSPF.FILE after the source file as a dependency. This is due to the tight integration between the program and its display file. By doing this, we ensure that the program is recompiled any time its display file is changed.

Building with Bob in Vscode

Once all of the above metadata files are set up for your project, building with Bob in VSCODE/Code4i is accomplished the exact same way that you did with Code4i actions in the previous post.

  1. Focus (click on) the source file that you wish to build
  2. Press Ctrl+e
  3. Choose Build current to build just the current file, or Build All.
  4. Choose your desired deployment method.
  5. The source file will be deployed to the IBM i partition’s IFS ‘deploy workspace directory’, then Bob will build. Job Logs will be returned to your workspace, as well as any messages listed in the evfevent file.

In our next CiCd post, we will add RPGLE linting to help us with formatting and defining rules for our RPGLE code

Share:
← ILE CiCd - Part 2 - Local Development Setup
ILE CiCd - Part 4 - RPGLE Linting →