User Tools

Site Tools


ibm_i_and_continuous_integration

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
ibm_i_and_continuous_integration [2017/03/18 09:19]
mihael [Build Steps]
ibm_i_and_continuous_integration [2017/05/25 19:20] (current)
mihael
Line 98: Line 98:
  
 The label determines where the job is run. This can be set on the "//​General//"​ tab, "//​Restrict where this project can be run//"​. Enter the label you specified on the IBM i slave node or enter the name of the slave node itself if it should run specifically on this node. The label determines where the job is run. This can be set on the "//​General//"​ tab, "//​Restrict where this project can be run//"​. Enter the label you specified on the IBM i slave node or enter the name of the slave node itself if it should run specifically on this node.
 +
  
 == Build Steps == == Build Steps ==
-<​sxh>​ +    ​git clone git@bitbucket.org:​m1hael/​linkedlist.git $WORKSPACE 
-git clone git@bitbucket.org:​m1hael/​linkedlist.git $WORKSPACE +     
- +    cd $WORKSPACE 
-cd $WORKSPACE +    $WORKSPACE/​setup
-$WORKSPACE/​setup +
-</​sxh>​+
  
 The source code is fetched from a git repository and the compile commands are in the ''​setup''​ script. The source code is fetched from a git repository and the compile commands are in the ''​setup''​ script.
Line 114: Line 113:
  
 {{:​ile_build_target_library.png}} {{:​ile_build_target_library.png}}
 +
 +
 == Example Setup Script == == Example Setup Script ==
 <sxh> <sxh>
Line 149: Line 150:
 fi fi
 </​sxh>​ </​sxh>​
 +
 +
 +== Tagging Build Objects ==
 +To identify from which source code revision the objects has been build we need to tag the objects with an identifier. The identifier could be the source code revision which can be retrieved from a git repository with the following line
 +
 +    git show -s --format=%h
 +
 +Output: ''​14b44a3''​
 +
 +To make sure that we only get the first 7 characters regardless of the output of the git command we can pipe the output to the ''​head''​ command like this
 +
 +    git show -s --format=%h | head -c 7
 +
 +QSYS objects can only store user information in two attributes:
 +
 +  * object description
 +  * user-defined attribute
 +
 +We will use the user-defined attribute though it can only hold 10 characters of information.
 +
 +The program //​UPDUSRATTR//​ available through the [[https://​github.com/​OSSILE/​OSSILE|OSSILE]] project can put this information on the object. We need to pass the following information as parameters:
 +
 +  * library name of the object
 +  * object name
 +  * object type (f. e. *PGM)
 +  * tag / user defined information (max. 10 characters)
 +
 +    CALL UPDUSRATTR PARM('​MSCHMIDT1'​ '​LLIST'​ '​*SRVPGM'​ '​GIT14b44a3'​)
 +
 +In the ''​setup''​ script it may look like this:
 +
 +    GIT_COMMIT_HASH=GIT$(git show -s --format=%h | head -c 7)
 +    system -kpieb "CALL MSCHMIDT1/​CIUPDOBJD PARM('​$TARGET_LIB'​ '​LLIST'​ '​*SRVPGM'​ '​$GIT_COMMIT_HASH'​)"​
  
  
Line 154: Line 188:
 I used ILEUnit for unit testing builds. There is also the RPGUnit framework but that doesn'​t support test report output to stream files. I used ILEUnit for unit testing builds. There is also the RPGUnit framework but that doesn'​t support test report output to stream files.
  
-TODO+The unit tests are service programs which must be build like the rest. There is a ''​setup''​ script which builds the unit test service programs. 
 + 
 +    cd $WORKSPACE/​unittest 
 +    $WORKSPACE/​unittest/​setup 
 + 
 +The execution of the unit test is also covered in the ''​setup''​ script. 
 + 
 +    system -kpieb "​IURUNXML IFS('​$WORKSPACE/​unittest/​llist_ut_1.xml'​) TSTLIB($TARGET_LIB) TSTPGM(LLIST_UT_1)"​ 
 +    if [ ! -e $WORKSPACE/​unittest/​llist_ut_1.xml ] ; then 
 +      exit 1  
 +    fi 
 + 
 +<note important>​It seems that the ILEUnit service program for stream file output is not report test failure and errors as expected. Errors (uncaught escape messages during the test) seems to break the test run. Failures (not matching asserts) are reported in the summary correctly but are not reported in the test case section for the test procedure. This renders unit testing with ILEUnit in Jenkins unusable.</​note>​ 
 + 
 + 
 +== Create Unit Test Report == 
 +In the previous step we run the unit test and create the xml stream files in the ''​unittest''​ folder in our Jenkins job directory. The files are automatically transferred from the slave to the master node. 
 + 
 +Now we need to say Jenkins where to find the files. 
 + 
 +{{ :​ile_build_publish_unit_test.png?​nolink |}} 
 + 
 + 
 +== Open Tasks == 
 +Jenkins provides a rich set of plugins. One of those plugins is the [[https://​wiki.jenkins-ci.org/​display/​JENKINS/​Task+Scanner+Plugin|Task Scanner Plugin]]. It is very flexible in identifying open tasks by keywords like //TODO// or //FIX ME//. The good thing is that it is also executed on the slave node so we can use it to scan the source code on the IBM i server. 
 + 
 +First we need to configure the keywords and the files to be scanned (in this case TODO and FIX ME as keywords and all files with the suffix //​rpgle//​). 
 + 
 +{{ :​ile_build_open_tasks_config.png?​nolink |}} 
 + 
 +The result of the scan looks like this: 
 + 
 +{{ :​ile_build_open_tasks_result.png?​nolink |}} 
 + 
 + 
 +== Lint == 
 +In almost any programming languages exists a lint module which does some generic code checking. Of course there is no such thing for RPG but one could do some checking with a simple text search using regex. 
 + 
 +An example would be if there shouldn'​t be any ''​DSPLY''​ command in the source code (left over from some testing or debugging session). So you could use the following regex to identify such lines: 
 + 
 +    .*[dD][sS][pP][lL][yY].* 
 + 
 +There is the Text Finder plugin which can be configured with any regex and the option to mark the build ''​UNSTABLE''​ if such a line is found. 
 + 
 +{{ :​ile_build_text_finder.png?​nolink |}}
  
  
Line 160: Line 238:
   * building documenation (ILEDocs)   * building documenation (ILEDocs)
   * making save file from compiled objects   * making save file from compiled objects
-  * tagging objects with git and build id 
   * ftp save file to archive   * ftp save file to archive
  
ibm_i_and_continuous_integration.1489828757.txt.gz · Last modified: 2017/03/18 09:19 by mihael