In this section:

build.id

This setting specifies a build identifier used to label results. It may be unique for each build but may also label more than one test sessions that were executed during a specified build.

The maximum length for a build ID is 128 characters.

Acceptable Values

[id]An id that is used to label results. The default is ${dtp_project}-${time:yyyy-MM-dd}.

Example Usage

The default build ID includes the name of the project in DTP and the date of the build. For example, for the ATM project, the build ID included in the report may resemble the following: ATM-2017-07-07. 

The following configuration specifies the custom build ID that consists of the name of the project and the build number passed via the environmental variable BUILD:

build.id=${dtp_project}-${env_var:BUILD}

For the ABC project and the build number 114 on a CI server, this may resolve to ABC-114.


dupcode.sorting.mode

This setting specifies how elements in the code duplication findings are sorted. 

Acceptable Values

oldestThe oldest result is displayed at the top.
newestsThe newest result is displayed at the top.
pathsDefault. The results are sorted by full path names in the ascending alphabetical order (A to Z).

exec.env

This setting specifies a string that describes the environment where the run was executed. It allows you to tag an entire testing session, as well as individual test suites, tests, or test cases via services API. By default, the tag is a combination of the operating system name (e.g., Windows, Linux) and its architecture (e.g., x86, x86_64).

Acceptable Values

[tag]A string that specifies the execution environment details. The default is ${os}${arch}.

Example Usage

The following configuration specifies that the run was executed on a 64-bit Linux machine with the GCC 5.4 compiler:

exec.env=linux_x86_64_gcc5.4


goal{n}.name

This setting specifies the name of a goal–a subset of findings that meet the specified criteria (see goal.severities, goal.projects, goal.max.to.recommend, goal.rules, goal.deadline). The findings are listed in the "Goals" section of the HTML report as recommended for each developer.

You can configure more than one goal by adding a number to the "goal" prefix.

Acceptable Values

[goal name]The name of the goal.

Example Usage

The following configuration enables two goals: "Priorities1" and  "Priorities2".

goal1.name=Priorities1

goal2.name=Priorities2

goal{n}.severities

This setting specifies the severity level of findings you want to be reported for a goal. This setting requires goal.name to be configured.

You can specify more than one severity.

Acceptable Values

[severity level]A severity level (1-5) or a comma-separated list of severity levels.

Example Usage

The following configuration enables the "Priorities1" goal that is a subset of findings with the severity level  1 or 2.

goal1.name=Priorities1

goal1.severities=1,2

goal{n}.max.to.recommend

This setting specifies the maximum number of findings reported for each developer in the "Goals" section of the HTML report. This setting requires goal.name to be configured.

Acceptable Values

[number]The maximum number of findings reported for each developer.

Example Usage

The following configuration specifies a reporting limit for the "Priorities1" goal to be 20.

goal1.name=Priorities1

goal1.severities=1,2

goal1.max.to.recommend=20

goal{n}.projects

This settings specifies that you want a goal to only include findings for a particular project. This setting requires goal.name to be configured.

Acceptable Values

[project name]The name of the project for which the findings are reported.

Example Usage

The following configuration specifies that the "Priorities1" goal will only include severity 1 and 2 findings reported for the "examples" project.

goal1.name=Priorities1

goal1.severities=1,2

goal1.projects=examples

goal{n}.rules

This setting specifies the rule(s) that you want to report findings for a goal. This setting requires goal.name to be configured.

Acceptable Values

[rule ID]A rule ID or a comma-separated list of rule IDs.

Example Usage

The following configuration specifies that the "Priorities1" goal will only include findings reported for the BD_SECURITY_VPPD  and BD_PB_VALRANGE rules.

goal1.name=Priorities1

goal.rules=BD_SECURITY_VPPD,BD_PB_VALRANGE

goal{n}.deadline

This setting specifies the deadline for fixing the findings. The number of findings reported for the goal depends on the time left to the deadline: the total number of findings is divided by the number of days left. This setting requires goal.name to be configured.

Acceptable Values

[YYY-MM-DD]The deadline date.

Example Usage

The following configuration specifies that all findings reported by the BD_SECURITY_VPPD  and BD_PB_VALRANGE rules are to be fixed by May 10, 2019.

goal1.name=Priorities1

goal.rules=BD_SECURITY_VPPD,BD_PB_VALRANGE

goal1.deadline=2019-05-10


goal.ref.report.file

This setting specifies the path to a reference report.xml file that will be used as a baseline to identify new findings during the current analysis. Findings detected in the current analysis run are marked as 'new' if they are not present in the reference file specified with this setting.

Acceptable Values

[path or URL]The path or URL to the reference report.xml file.

Example Usage

The following configuration specifies that findings detected during the current analysis will be compared against the report.xml file in the 'baseline' directory:

goal.ref.report.file=C:/parasoft/baseline/report.xml

goal.ref.report.findings.exclude

This setting enables or disables excluding existing findings from the report. Existing findings are identified by comparing findings detected in the current analysis run against the reference report.xml file report configured with goal.ref.report.file. If enabled, current findings that are also present in the reference file are excluded from the report.

Acceptable Values

trueOnly new findings are included in the report.
falseDefault. New and existing findings are included in the report.

Example Usage

The following configuration excludes existing findings from the report:

goal.ref.report.file=http://mycompany.com/sa/baseline/report.xml

goal.ref.report.findings.exclude=true

issue.tracking.tags

This setting specifies a list of issue tracking tags. It requires the report.associations option to be enabled.

Acceptable Values

[tag]

A comma-separated list of tags. The following tags are supported by default: asset, fr, pr, req, task, test

Example Usage

The following configuration disables the default tag asset and enables the custom tag high:

report.associations=true

issue.tracking.tags=fr,pr,req,task,high,test


project.module

This setting specifies a custom name for the project's module. The setting may be used to describe unique runs. If unspecified, the tested module is detected automatically based on the analyzed code.

Acceptable Values

[name]

A name of the project module.

Example Usage

The following configuration specifies the custom XTests module name:

project.module=xTests



report.active_rules

This setting specifies if the report contains a list of the rules that were enabled during analysis. 

Acceptable Values

trueDefault. The list of active rules is included in the report.
falseThe report does not include the list of active rules.

Example Usage

The following configuration disables showing the rules that were enabled during analysis in the report:

report.active_rules=false


report.archive

This setting enables or disables archiving reports into a ZIP file.

Acceptable Values

trueReports are archived in a ZIP file.
falseReports are not archived in a ZIP file.

report.associations

This setting enables or disables showing requirements, defects, tasks, and feature requests associated with a test in the report.

Acceptable Values

trueDefault. Requirements, tasks and feature requests are included in the report.
falseRequirements, tasks and feature requests are not included in the report.

Example Usage

The following configuration disables showing requirements, tasks and feature requests in the report:

report.associations=false

Related

Associating Tests with Development Artifacts


report.assoc.url.[tag]

This setting generates a link to an association inside the HTML report. The URL is a query string that contains an [%ID%] placeholder for the PropertyAttribute value. The associated tag must be configured with the issue.tracking.tags option.

Acceptable Values

[URL]

The link to the association that will be included in the HTML report.

Example Usage

The following configuration enables a custom tag high and generates a link in the HTML report.

report.associations=true

issue.tracking.tags=high

report.assoc.url.high=http://bugzilla.company.com/workitem?id=[%ID%]

Related

Associating Tests with Development Artifacts


report.authors_details

This setting specifies whether the report includes an overview of the number and type of tasks assigned to each developer.

Acceptable Values

trueDefault. Reports include types and numbers of tasks assigned to each developer.
falseReports do not include types and numbers of tasks assigned to each developer.

Example Usage

The following configuration disables including details about numbers and types of tasks for each developer:

report.authors_details=false



report.contexts_details

This setting specifies whether the report includes an overview of the files that were checked or executed during analysis.

Acceptable Values

trueDefault. Reports include a list of files that were checked.
falseReports do not include a list of files that were checked.

Example Usage

The following configuration disables including a list of files that were checked.

report.contexts_details=false


report.coverage.images

This setting specifies a set of tags that will be used to create coverage images in DTP. DTP supports up to 3 coverage images per report. 

Acceptable Values

[tag]

A semicolon-separated list of tags that will be used when coverage images are created in DTP.

report.coverage.limit

This setting that specifies the lower coverage threshold. Coverage results lower than the specified value are highlighted in the report.

Acceptable Values

[value]

A value that represents the lower coverage limit. The default value is 40.

Example Usage

The following configuration sets the lower coverage value to 50:

report.coverage.limit=50

report.coverage.line.hashes

This setting specifies if line hashes are included in the XML coverage report.

Acceptable Values

trueDefault. Line hashes are included in the coverage report.
falseLine hashes are not included in the coverage report.



report.custom.extension

This setting specifies the report file extension of the XSL file for a custom format. It requires the report.format option to be set to custom, as well as report.custom.xsl.file to be configured.

Acceptable Values

[extension]A custom extension of the XSL file.

report.custom.xsl.file

This setting specifies the location of the XSL file for a custom format.

Acceptable Values

[path]A path to the XSL file.

(info) Use double backslashes to specify the file path on Windows.


report.developer_errors

This setting specifies whether manager reports will include details about developer errors. 

Acceptable Values

trueDetails about developer errors are included in the report.
falseDefault. Details about developer errors are not included in the report.

Example Usage

The following configuration enables including details about developer errors in the report:

report.developer_errors=true



report.developer_reports

This setting specifies whether the system generates detailed reports for all developers (in addition to the summary report for managers).

Acceptable Values

trueEnables generating detailed reports for developers.
falseDefault. Disables generating detailed reports for developers.

Example Usage

The following configuration enables generating detailed reports for developers:

report.developer_reports=true



report.dtp.publish

This setting determines whether the current installation of the product reports results of local analysis to the DTP server.

Acceptable Values

true

The results are published to DTP.

falseDefault. The results are not published to DTP.

Example Usage

The following configuration enables sending local analysis results to DTP.

report.dtp.publish=true

Related


report.dtp.publish.src

This setting specifies whether the tested source code is published to the DTP server.  

Acceptable Values

offSource code is not published to DTP.
minThe minimal part of the source code is published (in most cases, source code without reference to source control, for example, auto-generated code, is published).
full

All of the source code from the specified scope is published to DTP. Default when the report.dtp.publish option is enabled.

Example Usage

The following configuration enables partial publishing of source code to DTP.

report.dtp.publish.src=min

Related


report.file.name

This setting specifies a custom name of the report file.

Note that this setting does not specify the file extension. You can specify the report format using the report.format setting.

  • The name "report" is restricted and should not be used.
  • If this setting is specified, and multiple formats with the same extension are selected, the reports will be overwritten.

Acceptable Values

[file_name] 

The name of the report file. For the default names, see Report File Names.

Example Usage

With the following settings configured, the results will be saved in the report-cwe.pdf file.

report.file.name=report-cwe

report.format=pdf


report.format

This setting specifies the report format. Use a comma separated list of formats to reports in more than one format.

Acceptable Values

xmlDefault. Generates a report in the XML format.
htmlDefault. Generates a report in the HTML format.
pdfGenerates a report in the PDF format.
csvGenerates a report in the CSV format.
sarifGenerates a report in the SARIF format.
sarif-azureGenerates a report in the Azure DevOps-specific SARIF format.
sateGenerates a report in the SATE format (see https://samate.nist.gov/SATE4.html for details)
sast-gitlabGenerates a report in the GitLab-specific SAST format.
xunitGenerates a report in the xUnit format.
customGenerates a report in a custom format; see report.custom.extension and report.custom.xsl.file.

Example Usage

The following configuration specifies the PDF report format:

report.format=pdf


report.graph.start_date

This setting specifies the start date for trend graphs that track static analysis task, test execution, and cover­age. Requires configuring the report.graph.period option.

Acceptable Values

[MM/dd/yy]

A date in the month-day-year format.

report.graph.period

This setting specifies the duration from the start date for trend graphs that track static analysis task, test execution, and coverage. Requires configuring the report.graph.start_date option.

Acceptable Values

[?d|?m|?y] 

Specifies the duration in the days-months-years format.


report.location

This setting specifies the directory where the report will be created.

Acceptable Values

[path]A path to the directory where the reports are created.

Example Usage

The following configuration specifies the path to the new_reports directory:

report.location=C:\\Users\\user1\\new_reports



report.mail.enabled

This setting enables or disables report emails to developers and additional recipients specified with the report.mail.cc setting. 

Acceptable Values

trueDevelopers and additional recipients are auto­matically sent a report that contains the errors/results related to his or her work. 
falseDefault.  Developers and additional recipients are not sent the reports.

report.mail.server

This setting specifies the mail server used to send reports.

Acceptable Values

[host_name] 

The host name of the server where the report will be sent.

report.mail.port

This setting specifies the port for SMTP  server.

Acceptable Values

[port_number] 

The port number. The default is 25.

report.mail.security

This setting specifies SMTP server connection security. 

Acceptable Values

STARTTLSDefault. STARTTLS connections security is used.
SSLSSL connections security is used.


report.mail.subject

This setting specifies the subject line of the emails that are sent.

Acceptable Values

[subject] 

The subject of the email.

Example usage

report.mail.subject=ABC Project Results

report.mail.username

report.mail.password

report.mail.realm

These settings specify required information for SMTP server authentication. The realm value is required only for those servers that authenticate using SASL realm.

Example Usage

report.mail.username=user1
report.mail.password=Psm#3P!

report.mail.domain

This setting specifies the mail domain used to send reports.

Acceptable Values

[domain] 

The domain where the reports are sent.

report.mail.time_delay

This setting specifies a delay between emailing reports (to avoid bulk email restrictions).

Acceptable Values

[time] 

The reports will be emailed with the specified time delay.

report.mail.from

This setting specifies the content of the "from" field of the emails sent.

Acceptable Values

[email]The "from" field will include the email address
[user]The "from" field will include the user name.

report.mail.attachments

This setting enables or disables sending reports as attachments. All components are included as attachments; before you can view a report with images, all attachments must be saved to the disk.

Acceptable Values

trueThe emails will be sent with attachments.
falseThe emails will be sent without attachments.

report.mail.compact

This setting specifies how the report information is delivered in the email. This setting is not configured by default.

Acceptable Values

trendsThe email contains a trend graph, summary tables, and other compact data; detailed data is not included
linksThe email only contains a link to a report available on DTP server.

report.mail.format

This setting specifies the content type for the email. 

Acceptable Values

htmlThe email content has the HTML format.
asciiThe email content has the ASCII format.

report.mail.cc

This setting specifies email address for sending comprehensive manager reports. Multiple addresses must be separated with a semicolon. This setting is commonly used to send reports to managers or architects, as well as select developers.

Acceptable Values

[email_address] 

A list of email addresses separated by semi-colons.

Example Usage

[email protected];[email protected]

report.mail.include

This setting specifies email addresses of developers that you want to receive developer reports.  Multiple addresses must be separated by a semicolon.  This setting is commonly used to send developer reports to developers if developer reports are not sent automatically (e.g., because the team is not using a supported source control system). 

This setting overrides addresses specified in the 'exclude' list.

Acceptable Values

[email_address] 

A list of email addresses separated by semi-colons.

report.mail.exclude

This setting specifies email addresses that should be excluded from automatically receiving reports.

Acceptable Values

[email_address] 

A list of email addresses separated by semicolons.

report.mail.exclude.developers

This setting enables or disables report emails to developers who are not explicitly listed in the report.mail.cc setting. This setting is used to prevent reports from being mailed to individual developers.

Acceptable Values

trueEmails will not be sent to developers who are not explicitly specified.
falseDefault. Developers are not excluded from the mailing list.

report.mail.unknown

This setting specifies where to email reports for errors assigned to "unknown".

Acceptable Values

[email]The reports assigned to "unknown" are sent to the specified email address.
[user]The reports assigned to "unknown" are sent to the specified user.

report.mail.on.error.only

This setting enables or disables email reports to the manager when an error is found or a fatal exception occurs. Developer emails are not affected by this setting; developer emails are sent only to developers who are responsible for reported errors.

Acceptable Values

trueEmails with specific information about errors and fatal exceptions are sent to the manager.
falseDefault. Emails with specific information about errors and fatal exceptions are not sent to the manager.

report.metadata

This setting specifies whether additional metadata about findings should be downloaded from DTP. Only the findings that are already available on DTP are affected. The DTP server must also support the metadata service for this setting to take effect.

Acceptable Values

trueDefault. Metadata about findings are downloaded from DTP.
falseMetadata about findings are downloaded from DTP.

Example Usage

The following configuration disables downloading additional metadata from DTP:

report.metadata=false



report.metrics.attributes

This setting specifies a list of additional attributes for metric results.

The following attributes are always enabled and don't need to be configured with this setting: module, namespace, type, method.

Acceptable Values

[attribute]

A list of comma-separated attributes.



report.rules

This setting specifies a directory for storing static analysis rules HTML files. 

Acceptable Values

[URL]

The location where the HTML static analysis rule files are stored.

Example Usage

Example 1:

report.rules=file:///C:/parasoft/gendoc/

Example 2:

report.rules=../gendoc/



report.scontrol

This setting specifies if and how much additional information from source control is included in the report.

Acceptable Values

offDefault. Information from source control is not included in the report.
minThe report includes information about repositories, file paths, and revisions.
fullThe report includes information about repositories, file paths, and revisions, as well as task revisions and comments.

Example Usage

The following configuration enables including  information about repositories, file paths, and revisions in the report:

report.scontrol=min



report.suppressed_msgs

This setting specifies whether the report includes suppressed messages.

Acceptable Values

trueSuppressed messages are included in the report.
falseDefault. Suppressed messages are not included in the report.

Example Usage

The following configuration enables including suppressed messages:

report.suppressed_msgs=true



report.setup.problems

This setting specifies where the Setup Problems section is placed in the report.

topThe Setup Problems section is placed at the top of the report.
bottomDefault. The Setup Problems section is placed at the bottom of the report.
hiddenThe Setup Problems section is not displayed in the report.

report.setup.problems.category_limit

This setting specifies a limit to the number of messages reported in a single setup problem category.

Acceptable Values

[number] 

The maximum number of messages reported in a single setup problem category. The default value is 10.

report.setup.problems.display_limit

This setting specifies a limit to the total number of messages displayed in the HTML report in the setup problem section.

Acceptable Values

[number] 

The maximum number of the total number of messages reported in the Setup Problem section. The default value is 100.

report.setup.problems.console

This setting specifies whether setup problems will be printed on the console.

Acceptable Values

trueDefault. Setup problems are printed to the console.
falseSetup problems are printed to the console.

report.separate_vm.xmx

This setting specifies how much memory should be used for reports generation. 

Acceptable Values

[memory_size] 

The maximum amount of memory allocated for report generation. The default is 120M.

report.separate_vm

This setting enables or disables generating reports as a separate virtual machine.

Acceptable Values

trueReports are generated as a separate virtual machine.
falseDefault. Generating reports as a separate virtual machine is disabled.

report.separate_vm.launch.file

This setting specifies the path to launch file that should be used during reports generation.

Acceptable Values

[path] 

The path to the launch file.

(info) Use double backslashes to specify the file path on Windows.


report.test_params

This setting specifies whether the report includes test parameter details. 

Acceptable Values

trueDefault. The parameter details are included in the report.
falseThe parameter details are not included in the report.



report.xml.param{n}.key

This setting specifies a custom parameter Id to be added to the xml report root element. Both report.xml.param{n}.key and report.xml.param{n}.value must be specified for the custom parameter to be added.

Acceptable Values

[id]A unique id of the custom parameter.

Example Usage

The following configuration specifies that an attribute with the given key and value will be added to the xml report root element.

report.xml.param1.key=customId

report.xml.param1.value=12345


report.xml.param{n}.value

This setting specifies a custom parameter value to be added to the xml report root element. Both report.xml.param{n}.key and report.xml.param{n}.value must be specified for the custom parameter to be added.

Acceptable Values

[value]A value of the custom parameter.

Example Usage

The following configuration specifies that an attribute with the given key and value will be added to the xml report root element.

report.xml.param1.key=customId

report.xml.param1.value=12345


session.tag

This setting specifies a tag for signing results from the test session. The tag is a unique identifier for the specified analysis process made on a specified module. Reports for different test sessions should be marked with different session tags.

You can create a tag using a string of characters, as well as the variables (see Using Variables).

Acceptable Values

[tag name]A unique tag that identifies results from different sessions. The default is ${scontrol_branch}-${exec_env}.

Example Usage

The default session tag includes variables that specify the source control branch name and the execution environment. For example, if source control integration is not configured, and the test session is performed on a 64-bit Windows, the report will include a session tag that may look as follows: ${scontrol_branch}-win32_x86_64.

The following configuration specifies a tag other than the default:

session.tag=ut_win

 
  • No labels