SonarLint and Code Pipeline

The use of SonarLint for sources that are managed by Code Pipeline is not directly linked to Jenkins pipelines but is important to consider in the context of DevOps. The SonarLint requires the sources to be stored in (or referenced via) an Eclipse project. For a mainframe development team, that usually means the extra effort of copying the sources from the mainframe SCM into an Eclipse project. If you are using a mainframe SCM and have an Eclipse based UI for this SCM, then copying your sources to another location to enable SonarLint to analyze the sources is a tedious and manual process. To alleviate this situation for customers using BMC's SCM Code Pipeline, we have introduced the concept of Code Pipeline projects. Even though, these will open the way for other integrations of third-party tools, typically used by distributed development teams, into a mainframe-based development process, the primary focus of Code Pipeline projects is enabling the use of SonarLint. From a mainframe developer's perspective, the term "project" and the use of projects and the way Code Pipeline projects are implemented might be confusing at first - especially when they are used to working with Code Pipeline.

Code Pipeline Applications and assignments

Usually, developers using Code Pipeline are working in the context of an assignment or release, which is a collection of different components into one container to be treated as one unit of work. Assignments are linked logically to a user story or similar. Depending on the requirements of the user story, the components within an assignment can originate from several different Code Pipeline applications. Consequently, assignments usually are very short lived, and as soon as the story is completed, they get closed.

On the other hand, applications are long lived, and serve as a high level way of grouping software components into a logical unit. This might be a whole business application or a sub-component of a large business application. Within these Code Pipeline applications, Code Pipeline keeps track of the versions of components belonging to the Code Pipeline application.

Eclipse projects

Other than the name project suggests, Eclipse projects are also not meant to be short lived objects keeping sources of components of an application for the duration of a development project, for example a user story, rather they store components for a business application or a component of a business application for the whole life time of this application. When it comes to version controlling the sources, Eclipse itself does not provide any means per default. Rather, third party tools like SVN or Git come into play.

During a development project like implementing a user story, Eclipse provides several tools and plugins that support with limiting the view onto the list of all projects to those elements that are important for one story. Some of these tools are Working Sets, Resource filters, and Task lists.

Code Pipeline projects

Consequently, Eclipse projects correspond more naturally to Code Pipeline applications than they would to other concepts within Code Pipeline. For this reason, when implementing Code Pipeline projects, BMC decided to base Code Pipeline projects on Code Pipeline applications. More precisely, an Code Pipeline project is defined by the Code Pipeline stream (a higher level grouping of Code Pipeline applications), Code Pipeline application, and the Path.

The latter is based on the Code Pipeline concept of a life cycle, which allows to define different, parallel ways a component can be promoted from development to production, thus allowing for parallel development on the same components. In the life cycle below, there are 4 parallel paths, 3 standard paths, moving components through a complete QA process and one path for emergency fixes, which allows for some shortcuts to be taken.

As a result, the Code Pipeline project's folder structure consists of the following:

The root that references the Code Pipeline application, stream and path
Sub folders corresponding to each component type
Files corresponding to each component

In addition, during creation of an Code Pipeline project from an Code Pipeline application, you can specify which component types and components are being tracked by the Code Pipeline project. This definition acts as a filter on the whole Code Pipeline application.

Tip

An Code Pipeline project only stores references to and meta data about components. The sources do not get downloaded to the workspace. Thus, no performance or disk space is wasted, and no sources are stored at two different places.
After defining an Code Pipeline project initially, users can modify the path the project is referencing and the filtering of the components and types.
If the sole purpose of using Code Pipeline projects is providing the integration point for using SonarLint, the only component types that are required for the Code Pipeline project are those that can be analyzed by SonarLint. In general, this would only be COBOL sources and copybooks. Any other component type, for example Assembler sources, JCL and suchlike, are not required for SonarLint.

Setting up the usage of SonarLint

Like any other Eclipse project, Code Pipeline projects need to be bound to SonarQube, in order for SonarLint to know, which rules to apply to the code it analyzes.

Tip

Even though there might be several different projects defined in SonarQube, serving different purposes, usually they all share the same set of COBOL rules to apply. Therefore, it simplifies things, if the local Code Pipeline projects in Eclipse are bound to the same master project within SonarQube.

From the technical standpoint the result can be viewed in the following way:

The component sources are stored and monitored in Code Pipeline and grouped by Code Pipeline application.
In the Eclipse workspace there is an Code Pipeline project folder structure, consisting of links to the components and meta data about them.
Each of these projects is bound to a SonarQube project.
SonarLint can analyze sources once they are opened by the developer.

This section provides information about the following topics: