Coverage files not mapped after upgrade to cli 3.1.7

[jgebal]

While trying new build pipeline with Azure on out uPLSQL-demo-project, I've decided to switch to latest utPLSQL-cli.
It was then, when I've noticed that coverage is not getting reported on project files.

At first I thought that it's related to build configuration itself but after a bit of unsuccessful debugging I've decided to switch to utPLSQL-cli v3.1.6

On utPLSQL-cli v 3.1.6 coverage is generated without issues.

The reason for missing coverage is missing/invalid files mapping.

Seems like regression in v3.1.7.

Worth noting is that utPLSQL-core is using files-mapping to narrow the scope of coverage.
When file names are passed in incorrect form, the result of mapping will be empty.

I suspect that either:

• the file mappings are getting passed in a different way (maybe swapped?)
• one of regex_expression, type_mapping, owner/type/name/subexpression is not passed correctly

The difference in behavior can be seen here:

• in test run with 3.1.7, coverage is empty and the sonar test_results.xml contains DB object_name as file_name.
• in test run with 3.1.6 coverage is populated and the sonar test_results.xml contains expected file_names.

[jgebal]

I did a bit of debug on utPLSQL itself to capture what is passed from cli.
Here are the outputs from invocations:

utPLSQL-cli v3.1.7

a_file_paths	<UT_VARCHAR2_LIST>
  <VARCHAR2>source\api\be_between.syn</VARCHAR2>
  <VARCHAR2>source\api\be_empty.syn</VARCHAR2>
...
  <VARCHAR2>source\uninstall_objects.sql</VARCHAR2>
  <VARCHAR2>source\uninstall_synonyms.sql</VARCHAR2>
</UT_VARCHAR2_LIST>
a_file_to_object_type_mapping	<UT_KEY_VALUE_PAIRS/>
l_file_to_object_type_mapping	<UT_KEY_VALUE_PAIRS/>
a_regex_pattern=	
a_object_owner_subexpression=	
a_object_name_subexpression=	
a_object_type_subexpression=	
a_file_paths	<UT_VARCHAR2_LIST>
  <VARCHAR2>test\common_helper\utplsql.pkb</VARCHAR2>
  <VARCHAR2>test\common_helper\utplsql.pks</VARCHAR2>
...
  <VARCHAR2>test\ut3_user\test_user.pkb</VARCHAR2>
  <VARCHAR2>test\ut3_user\test_user.pks</VARCHAR2>
</UT_VARCHAR2_LIST>
a_file_to_object_type_mapping	<UT_KEY_VALUE_PAIRS/>
l_file_to_object_type_mapping	<UT_KEY_VALUE_PAIRS/>
a_regex_pattern=	
a_object_owner_subexpression=	
a_object_name_subexpression=	
a_object_type_subexpression=	

utPLSQL-cli v3.1.6

a_file_paths	<UT_VARCHAR2_LIST>
  <VARCHAR2>source\api\be_between.syn</VARCHAR2>
  <VARCHAR2>source\api\be_empty.syn</VARCHAR2>
...
  <VARCHAR2>source\uninstall_objects.sql</VARCHAR2>
  <VARCHAR2>source\uninstall_synonyms.sql</VARCHAR2>
</UT_VARCHAR2_LIST>
a_file_to_object_type_mapping	
l_file_to_object_type_mapping	<UT_KEY_VALUE_PAIRS>
  <UT_KEY_VALUE_PAIR>
    <KEY>fnc</KEY>
    <VALUE>FUNCTION</VALUE>
  </UT_KEY_VALUE_PAIR>
  <UT_KEY_VALUE_PAIR>
    <KEY>prc</KEY>
    <VALUE>PROCEDURE</VALUE>
  </UT_KEY_VALUE_PAIR>
  <UT_KEY_VALUE_PAIR>
    <KEY>tpb</KEY>
    <VALUE>TYPE BODY</VALUE>
  </UT_KEY_VALUE_PAIR>
  <UT_KEY_VALUE_PAIR>
    <KEY>pkb</KEY>
    <VALUE>PACKAGE BODY</VALUE>
  </UT_KEY_VALUE_PAIR>
  <UT_KEY_VALUE_PAIR>
    <KEY>bdy</KEY>
    <VALUE>PACKAGE BODY</VALUE>
  </UT_KEY_VALUE_PAIR>
  <UT_KEY_VALUE_PAIR>
    <KEY>trg</KEY>
    <VALUE>TRIGGER</VALUE>
  </UT_KEY_VALUE_PAIR>
</UT_KEY_VALUE_PAIRS>
a_regex_pattern=	
a_object_owner_subexpression=	
a_object_name_subexpression=	
a_object_type_subexpression=	
a_file_paths	<UT_VARCHAR2_LIST>
  <VARCHAR2>test\common_helper\utplsql.pkb</VARCHAR2>
  <VARCHAR2>test\common_helper\utplsql.pks</VARCHAR2>
...
  <VARCHAR2>test\ut3_user\test_user.pkb</VARCHAR2>
  <VARCHAR2>test\ut3_user\test_user.pks</VARCHAR2>
</UT_VARCHAR2_LIST>
a_file_to_object_type_mapping	
l_file_to_object_type_mapping	<UT_KEY_VALUE_PAIRS>
  <UT_KEY_VALUE_PAIR>
    <KEY>fnc</KEY>
    <VALUE>FUNCTION</VALUE>
  </UT_KEY_VALUE_PAIR>
  <UT_KEY_VALUE_PAIR>
    <KEY>prc</KEY>
    <VALUE>PROCEDURE</VALUE>
  </UT_KEY_VALUE_PAIR>
  <UT_KEY_VALUE_PAIR>
    <KEY>tpb</KEY>
    <VALUE>TYPE BODY</VALUE>
  </UT_KEY_VALUE_PAIR>
  <UT_KEY_VALUE_PAIR>
    <KEY>pkb</KEY>
    <VALUE>PACKAGE BODY</VALUE>
  </UT_KEY_VALUE_PAIR>
  <UT_KEY_VALUE_PAIR>
    <KEY>bdy</KEY>
    <VALUE>PACKAGE BODY</VALUE>
  </UT_KEY_VALUE_PAIR>
  <UT_KEY_VALUE_PAIR>
    <KEY>trg</KEY>
    <VALUE>TRIGGER</VALUE>
  </UT_KEY_VALUE_PAIR>
</UT_KEY_VALUE_PAIRS>
a_regex_pattern=	
a_object_owner_subexpression=	
a_object_name_subexpression=	
a_object_type_subexpression=	

It seems that in 3.1.7, the parameter a_file_to_object_type_mapping is passed as empty array.
utPLSQL-core is using default object_type mapping when the passed argument is null.

Since empty array is not a valid value, we could treat empty array the same way we treat null and replace it with default mapping in utPLSQL-core.
This doesn't change the fact that for backward compatibility utPLSQL-cli needs to be fixed.

[pesse]

Okay, got it - we call it now as empty array but should pass as null when not set.
That somewhat contradicts my goals to become more immutable 🤪

Question: Is an empty mapping array ever a valid option? I don't think so but would be sure.
If not, I'll handle this in the api, so we don't rely on any client to distinguish between empty/null.

[jgebal]

Empty array is not a valid input as it will never cause a proper mapping.
Null/missing parameter is identified as "use defaults" directive for framework, just like with many other parameters.