Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Loads of stuff

...

To automatically upload the static analysis results into QA·Verify, select 'Upload results to QA·Verify'. This will enable uploading the project analysis as a snapshot to QA·Verify.

Enter the name of the QA·Verify project to be uploaded to. Once a project has been uploaded to QA·Verify, the project name must stay the same, or otherwise the snapshot will not be attached to the correct project. It is recommended to create that you first create the project first in QA·Verify, so that you can check verify that the project configuration is correct before uploading snapshots.

Code upload settings controls if control how the source code is uploaded to QA·Verify.

  • All code uploaded will unconditionally upload all source and header files to QA·Verify so it so they will not need to access the repository. The VCS can still be used during upload to get to obtaain the file versions and authors - specify a VCS configuration file below.
  • No code uploaded will not upload any code. QA·Verify will retrieve all required code from the repository. A VCS configuration file must be specified below.
  • Only code not in VCS will only upload files that are not in the Version Control System (e.g. generated files). Files that are in the repository will not be uploaded.

...

The number of messages generated by the PRQA static analysis can be compared against thresholds for build stability. If a threshold is exceeded, the build status is set to unstable. This can be used as a gate to stop gateway to prevent subsequent tasks from running.

The messages are organized into message levels according to the severity of the message, with Level 0 being the lowest.

The thresholds can be set to operate at a message level, allowing the severity of the messages to be taken into account. Code that contains low-severity maintenance and style issues may pass but code which code that contains critical issues would fail.

There are 3 are three kinds of threshold: Messages, File Compliance and Project Compliance.

...

This sets the message level from which the message total is calculated. Only messages from this level and above are summed to give the message total which total that is used for the Messages Threshold comparison. Note that File and Project Compliance thresholds are not affected by this setting.

Message Compliance Threshold

Either enter the maximum 'Maximum messages target' or select continuous 'Continuous improvement'.

The maximum 'Maximum messages target' is the total number of messages that are allowed on all levels for all the files in the project. Messages in header files are de-duplicated (i.e. they are only counted once and not for each source file file with which the header is included into).

The 'Message Compliance value' is the total number of messages for all the files in the project which are on the project that are at the 'Message Threshold Level' or above.

If the 'Message Compliance value' for the build is higher than the maximum 'Maximum messages target', the build is marked as unstable.

'Continuous improvement' states that the 'Message Compliance value' for the build will be less than or equal to the 'Message Compliance value' found in the previous build. If the 'Message Compliance value' for the build is higher, the build is marked as unstable.

Project Compliance Threshold

Either enter the project 'Project compliance target' or select continuous 'Continuous improvement'.

The project compliance 'Project Compliance target' is the minimum percentage of message groups (a coding standard ‘rule’) that have no messages in the project.

The 'Project Compliance Level level' is the percentage of message groups that have no messages in the project.

If the 'Project Compliance Level level' for the build is lower than the project compliance 'Project Compliance target', the build is marked as unstable.

'Continuous improvement' states that the 'Project Compliance Level level' for this build will be greater than or equal to the 'Project Compliance Level level' for the previous build. If the 'Project Compliance Level level' for the build is lower, the build is marked as unstable.

File Compliance Threshold

Either enter the file compliance 'File Compliance target' or select continuous 'Continuous improvement'.

The file compliance 'File Compliance target' is the minimum mean across all files of the percentage of message groups (a coding standard ‘rule’) that have no messages in each file.

The 'File Compliance Level level' is the mean across all files of the percentage of message groups that have no messages in each file.

If the 'File Compliance Level level' for the build is lower than the file compliance 'File Compliance target', the build is marked as unstable.

'Continuous improvement' states that the 'File Compliance Level level' for this build will be greater than or equal to the 'File Compliance Level level' for the previous build. If the 'File Compliance Level level' is lower, the build is marked as unstable.

A high 'File Compliance level' and low 'Project Compliance level' indicate that each file violates only a small number of rules but that each file violates a different rule.

If the 'File' and 'Project Compliance levels' are close, then each file is violating more or less the same rules.

If any of these thresholds are not met, then the build will be marked as unstable. Note that only configuration errors or analysis errors will mark the build as failed.

The PRQA Jenkins plug-in will be set by default to no 'No thresholds'.

PRQA Static Analysis results

...