Better support for test and coverage reports generated by utPLSQL

[felipebz]

Generating tests and coverage accurately with utPLSQL-cli can be quite challenging due to its mapping configuration, as illustrated in this guide.

Achieving accurate results can be challenging due to certain constraints, as outlined in the official documentation:

Object-file mapping rules

In order to allow deterministic and accurate mapping of database source-code into project files, the project directory and file structure needs to meet certain criteria.

• Source code is kept separate from test code (separate directories)
• Each database (source-code) object is stored in an individual file. Package/type specification is kept separate from its body.
• File name (file path) contains the name of database object
• Each file-path clearly identifies object type (by file extension)
• Each file contains representation of database object "as is". No extra commands (like set echo off ALTER SESSION SET PLSQL_CCFLAGS = 'debug:TRUE';) or blank lines are present before CREATE TYPE,CREATE TYPE etc.
• When project is spanning across multiple database schemes, each file-path clearly and uniformly identifies object owner

Generating a report without specifying any object-file mapping rule will return a report without file path. Examples:

<testExecutions version="1">
<file path="test_award_bonus">
...
</file>
<file path="test_betwnstr">
...

<coverage version="1">
<file path="function scott.betwnstr">
...
</file>
<file path="procedure scott.award_bonus">
...

The ZPA parser already parses all primary and test sources, and it can identify the file that declares the function scott.betwnstr. The core idea involves:

• Add the parameters sonar.zpa.tests.reportPaths and sonar.zpa.coverage.reportPaths into the plugin. These can be populated with the test and coverage reports, regardless of object-file mapping details.
• In cases where the file path is not mapped (as in the examples provided), the plugin will locate the file declaring the program unit and integrate the data into SonarQube.

This approach should overcome all the current limitations.

[felipebz]

With the the new sensor, importing utPLSQL test reports has been streamlined. The previous requirement for test file mapping in utplsql-cli will become obsolete. Users can exclusively rely on the newly introduced property sonar.zpa.utplsql.reportPaths for seamless integration.

Example: https://github.com/felipebz/utPLSQL-demo-project/commit/503d333bc41037d0001febe5d1d1de2a013f0411

[felipebz]

I am currently importing test and coverage data of the utPLSQL project to the SonarQube + ZPA demo instance.

The reports are generated using the following command, which does not include any object-file mapping argument:

utPLSQL-cli/bin/utplsql run UT3_TESTER_HELPER/ut3@${CONNECTION_STR} \
  -p='ut3_tester,ut3_user' --coverage-schemes=ut3_develop \
  -f=ut_coverage_sonar_reporter     -o=coverage.xml \
  -f=ut_sonar_test_reporter         -o=test_results.xml

The data is imported correctly without any errors or warnings, confirming that the implementation works properly:

INFO: Sensor Z PL/SQL Analyzer - utPLSQL Report Importer [plsqlopen]
INFO: Processing test report /github/workspace/test_results.xml
INFO: Processing coverage report /github/workspace/coverage.xml
INFO: Sensor Z PL/SQL Analyzer - utPLSQL Report Importer [plsqlopen] (done)

This should be enough for most users.