Coverage files not mapped after upgrade to cli 3.1.7

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.

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.

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.

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.

Default TypeMapping is used on NULL and also empty typeMap parameter

Navigation Menu

Repository navigation

Coverage files not mapped after upgrade to cli 3.1.7 #162

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Coverage files not mapped after upgrade to cli 3.1.7 #162

Description

Activity

jgebal commented on Jul 14, 2019

pesse commented on Jul 15, 2019

jgebal commented on Jul 15, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions