Skip to content
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.

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

Question - limiting the types to ignore triggers #215

Open
clarkec21 opened this issue Dec 23, 2022 · 2 comments
Open

Question - limiting the types to ignore triggers #215

clarkec21 opened this issue Dec 23, 2022 · 2 comments
Labels

Comments

@clarkec21
Copy link

Hi
I am calling utplsql-cli via GitHub Actions on a runner server on OCI as ADMIN user. I pass in multiple schemas to be processed and am writing the documentation to a file and coverage html to a file. My question is: I do not want to report on coverage for triggers and I am not using Projects and files I am only using the database. Can yo advise how I do this.

@jgebal
Copy link
Member

jgebal commented Jan 16, 2023

At the moment there is no way to include/exclude objects in coverage by object type in utPLSQL core framework.
Also, the option for inclusion/exclusion of objects by regular expression is not implemented in utPLSQL-cli.

So your only option currently would be to provide a long list of object names to exclude.

It seems like a potential gap in utPLSQL capabilities.

Do you have a naming convention for triggers that would make it possible to exclude objects by part of name (prefix/suffix etc?)
Would filtering by list of object_names be an option?

Why does it hurt to have Triggers in the report? Are they not part of the project source-code?

@clarkec21
Copy link
Author

Hi @jgebal thnks for your reply

I should have explained our triggers either contain calls to packages (already utplsql tested) or standard code auto generated by us to write to history/journal tables - the testing of these is a bit of an overhead.

We do have a standard naming convention but wildcards are not utilised so I would have to maintain a large ever changing list - we can just include in the coverage report them but ignore their % for now. Any progress on Issue 212 should help us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants