Jenkins Workflow

Jenkins is a popular Open Source implementation of a build automation server . From its Wikipedia description, Jenkins:

“is a server-based system that runs in servlet containers such as Apache Tomcat. It supports version control tools, including AccuRev, CVS, Subversion, Git, Mercurial, Perforce, ClearCase and RTC, and can execute Apache Ant, Apache Maven and sbt based projects as well as arbitrary shell scripts and Windows batch commands.”

It is used, typically by a Development Operations (DevOps) Engineer, to create automated processes that cause software projects to get built and tested automatically based upon various criteria set by the DevOps developer as part of a Continuous Integration/Continuous Deployment (CI/CD) framework.

It is expected that many users of iCR will want to incorporate it into their CI/CD frameworks. This section outlines the steps of how iCR may be integrated into a Jenkins workflow. The diagram below will be used as the reference for the steps.

Step 1. The first step is for the person creating the workflow, typically an engineer familiar with DevOps and with the Jenkins workflow framework, to determine where in the workflow the iCR step will be triggered. The step is implemented as a Jenkins plugin, installed as described in Installing the plugin. It is assumed that the iCR service has already been correctly installed upon an existing privately managed server platform.

Step 2. Once the iCR step is inserted into the workflow and properly configured as outlined in Configuring the iCR plugin, it will generate an event that will cause the Navigator on the configured iCR server to become active. Although the communication between the plugin and the Navigator is over http, the plugin and the Navigator use encryption to keep the information sent between the plugin and the Navigator private.

Step 3. The Navigator will use information provided from the iCR plugin in the workflow to determine the correct repository to be analyzed. The Navigator will automatically fetch the source code from the configured repository (from GitHub, GitLab or BitBucket), select the configured branch and initiate an analysis.

Step 4. The Navigator monitors the Analysis as it may take some time to complete depending upon the size and complexity of the code being analyzed. Once the analysis completes, the user is notified via an email message. The email is sent to the address configured into the plugin. An email address MUST be provided so that iCR has a way of not only signaling completion, but also a way of communicating any errors that may have occurred.

Step 5. Once notified that analysis is complete and that results are available, the user may login directly to the iCR server which ran the analysis. From that login, the user can enter the Reviewer to process results in exactly the same manner as described in the User Guide for Private Platforms.