Versions Compared

Old Version 4

changes.mady.by.user Robert Andelin

Saved on

compared with

New Version Current

changes.mady.by.user Robert Andelin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space FUNCTDEV and version SVC2025.1

...

Table of Content Zone
maxLevel3
minLevel3
locationtop
styledisc
classwar-file-settings-list
Info
titlePaths with spaces or special characters

Paths containing spaces or special characters must be URL-encoded the same way in the exclude/includes properties.

http.proxy.deployment.path.includes

This option defines paths allowed for HTTP proxy deployment by specifying a path prefix. Multiple paths can be specified as a comma-separated list. This ensures that only paths starting with the given segment are permitted, helping teams manage their service deployment routes and avoid conflicts by clearly identifying valid paths for each team. Proxy deployments configured with HTTP listeners are not affected.

The check is based on whether the path starts with the specified path segment. For example, if the includes property is set to /teamA, then paths like /teamA and /teamA/projects are allowed. However, paths like /teamAnother or /teamA123 will be disallowed, as they do not begin with the specified segment.

http.proxy.deployment.path.excludes

This option defines paths for HTTP proxy deployment that should be explicitly blocked by specifying exact matches. Multiple paths can be specified as a comma-separated list. This helps teams prevent certain paths from being used for their service deployments, ensuring that conflicting or unauthorized routes are excluded. Proxy deployments configured with HTTP listeners are not affected.

The path check is exact, so the specified path must match exactly. For example, if the excludes property is set to /teamA, then the path /teamA will be disallowed, but paths like /teamA/projects or /teamB will still be allowed, as they do not exactly match /teamA. By default, paths on root are disallowed.

virtual.asset.deployment.path.includes

This option defines paths allowed for virtual asset deployment by specifying a path prefix. Multiple paths can be specified as a comma-separated list. This ensures that only paths starting with the given segment are permitted, helping teams manage their service deployment routes and avoid conflicts by clearly identifying valid paths for each team.

The check is based on whether the path starts with the specified path segment. For example, if the includes property is set to /teamA, then paths like /teamA and /teamA/projects are allowed. However, paths like /teamAnother or /teamA123 will be disallowed, as they do not begin with the specified segment.

virtual.asset.deployment.path.excludes

This option defines paths for virtual asset deployment that should be explicitly blocked by specifying exact matches. Multiple paths can be specified as a comma-separated list. This helps teams prevent certain paths from being used for their service deployments, ensuring that conflicting or unauthorized routes are excluded.

The path check is exact, so the specified path must match exactly. For example, if the excludes property is set to /teamA, then the path /teamA will be disallowed, but paths like /teamA/projects or /teamB will still be allowed, as they do not exactly match /teamA. By default, paths on root are disallowed.

virtual.asset.deployment.path.enforce.unique.basepaths

This option specifies whether virtual assets are required to be deployed on unique base paths. When set to true, deploying assets on common base paths is prohibited, thus ensuring that assets cannot be deployed on paths that may be conflicting. When set to false, deploying multiple virtual assets on the same base path is allowed. Default is false.

Examples

The following scenarios illustrate how this option works when enabled:

Scenario 1: Deployment Conflict with an Exact Path

If the property is set to true and an existing asset is deployed on /api/v1/cartItems, all other assets attempting to deploy on the same path /api/v1/cartItems will be disabled.

Scenario 2: Deployment Conflict with an Ancestor Path

If the property is set to true and an existing asset is deployed on /api/v1, all other assets attempting to deploy on paths /api/v1/cartItems, /api/v1/orders, or any other paths with /api/v1 as an ancestor will be disabled. However, an asset deployed on /api/v2 will still be allowed, since /api/v1 is not an ancestor path of /api/v2.

Scenario 3: Deployment Conflict with a Descendant Path

If the property is set to true and an existing asset is deployed on /api/v1/cartItems, all other assets attempting to deploy on paths /api/v1 or /api will be disabled, as /api/v1/cartItems is a descendant of these paths. However, assets deployed on /api/v2 or /api/v1/orders will still be allowed, since /api/v1/cartItems is not a descendant of these paths.

Info
titlePaths with spaces or special characters

Paths containing spaces or special characters must be URL-encoded the same way in the exclude/includes properties.

Report Settings


Table of Content Zone
maxLevel3
minLevel3
locationtop

session.tag

This setting specifies a tag for signing results from the test session. The tag can be a string, one or more variables, or a combination. Reports for different test sessions should be marked with different session tags so that similar runs can be distinguished from each other. The default is session.tag=${config_name}

Example Usage

You can use the session tag to represent a specific analysis type made on a specific code branch in a specific test environment. The following configuration could identify functional tests on the main branch for different operating systems:

session.tag=ft_main_${os}

build.id

This setting specifies a build identifier used to label results. It may be unique for each build, but it may also label more than one test session executed during a specified build. The default is ${dtp_project}-${time}.

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.

report.format

This setting specifies the report format. Use a comma separated list of format values to publish reports in more than one format. By default, an XML report containing the data and an HTML file for presenting the data are published. The following values are supported:

report.custom.extension

This setting specifies the file extension for a custom report. Custom formats are defined in an XSL file. The report.format option must be set to custom and the report.custom.xsl.file option must also be configured.

report.custom.xsl.file

This setting specifies the path to an XSL file used to create a custom report format. Use double backslashes when specifying the file path on Windows.

report.developer_errors

This setting determines if details about developer errors should be included in manager reports. Set to true to include developer errors in reports or set to false to exclude developer errors in reports. The default is true.

report.developer_reports

This setting determines if detailed reports for all developers should be generated in addition to the summary report for managers. Set to true to enable generating detailed reports for developers. Set to false to disable generating detailed reports for developers. The default is true.

report.authors_details

This setting determines if an overview of the number and type of tasks assigned to each developer should be included in the report. Set to true to include types and numbers of tasks assigned to each developer. Set to false to exclude types and numbers of tasks assigned to each developer. The default is true.

report.testcases_details

This setting determines if additional test case details should be included in the report. Set to true to include additional details about test cases. Set to false to exclude additional details about test cases. The default is false.

report.associations

This setting enables or disables showing requirements, defects, tasks, and feature requests associated with a test in the report. Set to true to include requirements, tasks, and feature requests in the report. Set to false to exclude requirements, tasks, and feature requests from the report. The default is false.

report.assoc.url.[tag]

This setting generates a link to an association inside the HTML report. The URL is a query string containing an [%ID%] or ${id} placeholder for the issue identifier. Supported tags are pr, fr, task, req, and test.

Example Usage

The following example creates a link to a PR in Bugzilla in the HTML report:

report.assoc.url.pr=http://bugzilla.company.com/show_bug.cgi?id=[%ID%]

report.failed_tests_only

This setting determines if only tests that failed should be included in the report. This option is only valid for functional testing tools. Set to true to only include tests that failed in the report. Set to false to include all tests in the report. The default is false.

report.env_details

This setting turns on additional details in the XML report about the active environment used when running a tst. The default is false.

report.output_details

This setting turns on additional details in the XML report about output tools that were executed when running a tst. The default is false.

report.test_suites_only

This setting determines if summary section of the report lists only top-level suites or if it displays a tree-like view of the individual tests. Set to true to only include top-level suites in the summary section of the report. Set to false to include a tree-like view of the individual tests. The default is true.

...