As the topic of the thesis suggests, its goal is to find a way to integrate Static Code Analysis tool with Defect Tracking tool. Section 4.2 however shows that integration between JIRA and Klocwork is very limited due to the functionality offered to the developers by Klocwork.
As the result of the feasibility analysis of the Klocwork — JIRA integration shows it is not possible to make use of a lot of functionality valuable for JIRA users across ACS. Thus it is necessary to find another way to use the data retrievable from Klocwork to its fullest potential. The feasibility study of integration between JIRA and Fisheye proves to be one of the ways this thesis can bring more value to the development process.
4.2 Klocwork
When implementing an integration between two different systems, it is necessary to ana-lyze the range of possibilities the systems provide for integration. As Atlassian JIRA and Klocwork are two completely unrelated systems, they do not have any native interface for connecting with each other. There are two approaches available for gathering data from each of the systems, each having its pros and cons.
• Database access
• Web services
Knowledge of database schema with access to the database provides possibility to get all the data the system manages. Being dependent on database schema however makes the integration very inflexible especially as neither JIRA nor Klocwork provide their database schemas publicly. It is impossible to fully anticipate the changes in the database schema and thus the integration is very likely to fail.
Both systems however provide WEB APIs. JIRA provides flexible and extensive WEB API which is even more extensible by implementing JIRA plug-in. Klocwork provides less flexible WEB API which allows the users only limited access to the data. WEB APIs are less prone to being radically changed or changed without having public knowledge about it. The implementation will use these WEB APIs to fulfill the integration and build new functionality.
4.2. KLOCWORK There are two steps that are generally executed when communicating with another sys-tem, Authentication and Retrieving/Updating the data on the external system. It is nec-essary to keep the order of the steps as unauthenticated user is not allowed to retrieve or update any data on any of the two systems.
First of the steps is authentication of the user executing any functionality on the external system. JIRA provides the user with different approaches for authentication.
• Basic Access Authentication:The simplest method for an HTTP user agent to pro-vide user name and password when authenticating.
• OAuth:The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf [16].
• Trusted Applications:Creates trusted way to communicate between the applications not requiring to log into external system again when accessing them.
Figure 4.1: Creating Authentication Token to Klocwork
Klocwork provides only one way of authentication of user accessing the data by WEB API. It uses Authentication Token for authenticating the user through its WEB API. Gener-ating and retrieving the token is executed in two steps as shown in Figure 4.1.
1. Executing kwauth utility, provided by Klocwork Server installation. User login name, password and optionally server URL is required for this step.
2. Extracting authentication token from a file named ltoken, stored in .klocwork folder inside the profile folder of user executing the operation.
• The record in ltoken file has the following form:
– serverUrl;port;userLoginName;authenticationToken
• AuthenticationToken can be extracted from the file and used later in building the REST URL.
4.3. FISHEYE
• The token is presented as value for ltoken attribute in REST call URL.
As the only option to authenticate the user is by the use of external utility on a computer on which Klocwork server is installed it is not possible to make authentication for each in-dividual user logged into JIRA. An account serving for access to Klocwork by all JIRA users is necessary. According to Honeywell policy it is possible to maintain a Technical Account which can get authenticated against Klocwork. The authentication token of the authenti-cated Technical Account will be stored as part of the JIRA plug-in for later use in building the REST URL.
The second step in communicating with an external system is using the system’s func-tionality for our purposes. Table 4.1 lists possible uses of WEB API provided by Klocwork.
Create Retrieve Update Delete Generate Import
Project X X X
Table 4.1: Klocwork WEB API capabilities
Table 4.1 shows that the API provides a variety of functionality for creating, retriev-ing, deleting and updating projects, modules and views. This master thesis however deals mostly with Detected Issues (Klocwork findings) which are the main target for our work.
Klocwork restricts us from working with these Klocwork findings to one operation which is retrieving the data.
The API does not allow any modifications to existing Klocwork findings which means, it is not possible to use JIRA as the primary tool to work with findings (e.g. updating the status or commenting) at this time. Proposed features for the integration will only retrieve the data from Klocwork without the possibility to further modify them.
4.3 Fisheye
Fisheye, like JIRA, is a product from Atlassian. Even though JIRA does not provide implicit integration between systems, Fisheye WEB API supports more flexible functions and what
4.4. CONCLUSION is more important, native authentication mechanism which helps the developer avoid im-plementing their own way of dealing with security issues.
The Fisheye WEB API provides the developers with the following functionality1
• Commit Graph data
– retrieves detailed information about a set of changesets in a repository, designed to be used with the Fisheye commit graph.
• Getting information about changesets and file revisions indexed by Fisheye – get a list of changesets on a repository,
– get specific changeset from repository,
– get a list of information about files and directories in a path, – get a specific file revision,
– get a list of the file revisions for a specific path.
• List information about the repositories.
• List of changesets from a repository.
• Execute Fisheye queries against a repository,
– execute a Fisheye query against a specific repository, – list of reviews for a changeset in a given repository,
– list of reviews for each given changeset in a given repository.
4.4 Conclusion
The previously summarized functionality of each system shows that with the right precon-ditions, described for each feature separately, being fulfilled from the part of JIRA users, it is possible to create features which should at the end make the quality of the code and individ-ual features higher and the development time of features reduced. It is possible to aim for creating features which will map Klocwork findings to specific JIRA Issues automatically.
1. Fisheye WEB API <https://docs.atlassian.com/fisheye-crucible/latest/wadl/fisheye.
html>
Chapter 5
Integration Implementation
As Section 1.2, the integration will be implemented as a JIRA plug-in, gathering all necessary data from both Klocwork and Fisheye and process them into more complex and valuable information. The first step of the implementation is to create common functionality and features which will be subsequently used by other features across the JIRA plug-in.
Both JIRA and Klocwork consist of projects, while Fisheye consists of repositories for the code base. At this time, each JIRA project and Klocwork project in Honeywell ACS include the same codebase which is also part of one Fisheye repository. JIRA projects, Klocwork projects and Fisheye repositories are not implicitly mapped by their code bases. This map-ping is the first precondition for further work with the data gathered in JIRA.
JIRA provides a feature called Application Links. Application Links (sometimes called
“AppLinks”) are implemented via a bundled plug-in that allows to link JIRA, Confluence, Stash, Fisheye, Crucible and Bamboo applications. Linking two applications allows sharing information and access one application’s functions from within the other. Application Links also allow users of Atlassian products to link them to external non-Atlassian systems in case an Application Link Type is implemented as part of a custom plug-in [17].
Figure 5.1: Data Flow