A plugin for doing static code analysis using PRQA.
This plugin was developed and maintained by Praqma up til release 1.2.2.
For later releases Praqma is no longer to the maintainer of this plugin and service and feature requests should be directed directly to Programming Research.
This plugin is able to analyze configured PRQA projects.
The plugin will allow you to configure PRQA Tool to support old analysis interface for QA·C, QA·C++ and new analysis interface using QA·Framework.
The plugin will allow you to automate the creation and analysis of PRQA enabled projects, present the overall analysis, and enable you to perform the analysis as a part of your continuous integration strategy.
The plugin will display a graphical history depicting the number of messages, and overall compliance levels in your project.
As of version 1.1.0 we can now also upload projects to QA·Verify Server.
Download the latest version manually HERE or alternatively, use the Jenkins CI Update Center.
Prior to installing and using this prqa plugin the user must ensure that the the following PRQA applications are installed:
If you wish you can use the plugin to setup the environment for you. You do that by going from 'Manage jenkins' -> 'Configure System'. You should see an option to add a QA·Framework Installation Configuration.
This is an example of a QA·Framework configuration, where we have entered the default installation directories. The plugin will automatically expand locations and add the necessary bin folders to your path.
You can add as many of QA·Framework as you like, and plugin allows to have multiple versions of the QA·Framework installed. A best practice is to include the QA·Framework version number (or some other identification) in the Installation Name, rather than just using 'QA·Framework'.' installed on your machine, so if you need to add Installation Names for new version of the tool - it's easier to see exactly which version you want to use when configuring the job.
Click on "Add post-build action" and select Programming Research Report
you have two options per post-build action, either you can select QA·Frameowrk (if you are using new user interface for PRQA Solutions) or Existing PRQA Tool for old user interface.
Programming Research Report for QA·Framework
Select QA·Framework option by clicking on radio button
Setup section will allow you to select the QA·Framework installation configuration along with project specific settings.
Installation options are configured in the QA·Framework section in the global Jenkins configuration, you need to select one of the configuration (Refer - QA·Framework Setup section)
Enter the path to the directory containing the prqaproject.xml project file to be analyzed.
if you don't have prqa project created for your project then you can follow the below instructions.
Make your you have option to add build setup and it is above "Post-build Actions" . If this option is not available the please check your Jenkins plugin.
If your build machine is a windows machine then select "Execute Windows batch command" option or select Execute shell option.
you can use command line interface for QA·Framework and perform administrative functionalities like setting debug level and license server to make sure that the tool is set and licenses are available.
Plugin will automatically run project analysis and produce the report. Enabling "Generate report" option will add "Rule Compliance Report" to build artefacts.
If you already have cross module analysis (CMA) project and you want to perform CMA analysis then you need to select "Perform Cross-Module analysis" option and specify CMA project.
Upload result to QA·Verify:
you need to select a server configuration to be used when uploading to QA·Verify.
you can select default QA·Verify Config file and VCS Config file located under "config" directory of product install directory.
Prior to installing and using this plugin the user must ensure that the the following PRQA applications are installed:
The following programs must on the path on the machine who hosts the job.
Note: When the plugin runs a program it will call it with just it's name, for example to run QA·C it will run 'qac'. This can cause a problem on Windows where the executable is called 'qac.exe' and there is a shortcut in the same directory (or earlier in the %PATH%) called 'qac.lnk'. Under the Windows command shell rules, 'qac.lnk' will be run before 'qac.exe' when the command 'qac' is given. Rename the shortcut if this happens.
It is also required that QA·C and QA·C++ have the following environment variables set:
The environment for QA·C and QA·C++ can be setup using a batch file or shell script supplied with the tools in their bin directories. Thus the following commands can be used to setup the environment:
These settings must exist in the environment that the slave runs in, though how they are set depends on how the slaves are launched. The simplest solution is to add the required settings to the system environment. Alternatively they could put into the startup or login script for the user that runs the Jenkins slave.jar file.
If you wish you can use the plugin to setup the environment for you. You do that by going from 'Manage jenkins' -> 'Configure System'. You should see an option to add a PRQA Product Configuration.
This is an example of a PRQA Product Configuration, where we have entered the default installation directories. The plugin will automatically expand locations and add the necessary bin folders to your path.
It is best to include the product version number (or some other identification) in the Installation Name, rather than just using 'QAC' or 'QAC++' on the job configuration page which it's easy to get confused with (these entries are form the original version of the plugin and have been retained for compatibility). The other reason is if you need to add Installation Names for new version of the tool - it's easier to see exactly which one you want when configuring the job.
The analysis is configured to run as a post-build step.
Setting it up you have two choices:
When you select file list no primary analysis is done, and we assume that the files have been analyzed beforehand. Selecting a Project file as report source will run primary analysis. The configuration looks like this:
The values for all the fields you're required to enter can either be absolute, or relative to the workspace.
The Project file should have been saved with relative paths (on Windows) or using environment variables (on Windows or Linux). This ensures that project correctly refers to all the files within it wherever it is checked out. The typical exception to this is the Compiler Personality, which usually has an absolute path since it is specific to the machine. It is assumed that all slaves are identical, so the path to the PRQA Project file in the plugin settings can be absolute, as the project will always be built in the same path location, whatever slave it is built on.
You have the option to use several advanced analysis options, including CMA, dependency based analysis, and dataflow analysis.
The first set of checkboxes are self explanatory, do you wish to create additional reports alongside the Compliance report?
The 'Add threshold' button is used to add thresholds to build stability. We currently have 3 kinds. Messages, File Compliance and Project Compliance.
only have messages between the level 5 and 9 count towards the total.
The configuration section for each threshold has 2 values.
A build will never be marked as 'Failed' when doing the comparison, only configuration errors or analysis errors will mark the build as Failed.
The plugin will default to 'None' in the initial configuration.
As of version 1.1.0 we support uploading of projects to QA·Verify servers.
In order for that to work, you'll need to configure a QA·Verify server instance, this is done in the Jenkins Global Configuration pages. The section you should look out for looks like this:
Look for PRQA Plugin Global Configuration
Press Add and type in the correct credentials for your QA·Verify Server user.
Now you're ready to configure your PRQA enabled Jenkins job to use this server.
On you job configuration page, checking 'Upload to QA·Verify' will expand into the following:
The fields here should be self explanatory. It enables you to select the VCS Configuration file, whether all code should be uploaded, and where the source origin is located.
The source origin will default to the current workspace if nothing is specified, and is used on the QA·Verify server to specify the top level of the source directory structure. It is used to remove the leading parts of pathnames, so the paths to files (in the Web Message Browser for example) are shown from the project root only. .
The plugin will create graphs showing the current number of messages and the current project compliance levels. The Jobs project pages (Front page will display something like this)
This allows consolidated logging, which basically means that any output from the built in java logger ends up on the master. We have added a lot of tracing statements through the plugin components, which will allow us to quickly locate and fix eventual future discovered defects.
The logging plugin will be available for installation through the Jenkins Update Center.
Skip to end of metadata Go to start of metadata