Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Coverage files not mapped after upgrade to cli 3.1.7 #162

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
jgebal opened this issue Jul 14, 2019 · 3 comments · Fixed by utPLSQL/utPLSQL-java-api#90
Closed

Coverage files not mapped after upgrade to cli 3.1.7 #162

jgebal opened this issue Jul 14, 2019 · 3 comments · Fixed by utPLSQL/utPLSQL-java-api#90
Assignees
@pesse
Labels
bug

Comments

@jgebal
Copy link
Member

jgebal commented Jul 14, 2019

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
Copy link
Member Author

jgebal commented Jul 14, 2019 •
edited
Loading

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.

@jgebal jgebal added the bug label Jul 14, 2019
@pesse pesse self-assigned this Jul 15, 2019
@pesse
Copy link
Member

pesse commented Jul 15, 2019

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
Copy link
Member Author

jgebal commented Jul 15, 2019

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.

pesse added a commit to utPLSQL/utPLSQL-java-api that referenced this issue Jul 16, 2019
@pesse
Default TypeMapping is used on NULL and also empty typeMap parameter
952d344 
Fixes utPLSQL/utPLSQL-cli#162
This was referenced Jul 16, 2019
Merged
Closed
@pesse pesse mentioned this issue Oct 16, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pesse pesse

Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Bugfix/coverage key value parameter utPLSQL/utPLSQL-java-api
2 participants
@jgebal @pesse