Is there a way to extend on the default code file extensions without have to include all the default file types

[dave-schmitz1]

I have been testing this out on one of repositories and noticed the default code file extension did not include a lot of file types for our C# project such as .csproj, .sln, .props, .targets, as well as other file types I feel needs to be included in the metrics. From the looks of it, there is only 3 specific file types for C# but none of the ones I mentioned are included. I prefer not to have to pass all the default code file type and only add the ones I don't see being scanned. Any help would be greatly appreciated.

[muiriswoulfe]

Hi Dave,

Thanks for using PR Metrics.

The behaviour you see is by design – we explicitly don't include .csproj, etc as we want to focus on code changes rather than configuration changes. This design was settled on after a significant amount of refinement. The rationale is that configuration changes are typically trivial or at least simple to review, whereas the real changes that contribute to review time are within the .cs files.

We understand, however, that this doesn't work for everyone, which is why the code-file-extensions parameter is provided. The behaviour of this is that you need to specify all the extensions that are in scope, which I understand doesn't work perfectly for you. But I believe you should be able to get this to work. Think about the following:

• Do you really need to include .csproj, etc given the findings I mentioned above?
• If so, can you just include the set of extensions used within your project today? I suspect you wouldn't need to include everything checked for by PR Metrics currently as you likely will never use most of the languages included in the defaults. That should help scope down the problem.

Hope this helps.

[dave-schmitz1]

Hi Muiris,

Thank you for the feedback. Just so I understand this correctly, if I use the default code file extensions and I have a large code change that has a small amount of product code versus a large amount of "ignored" code what would be the impact? Right now we have a few large brownfield repositories we'd like to apply this to but want to know the impact of "ignored" versus what its actually listed as "product" and "test" code. Will this have any direct result on the pull request sizing or is the objective to try and add values to the code-file-extension to capture as much of the code as possible? The way I see it, I have a few options including simply using the default extensions, doing a one-time export of all code extension types and using the override option, or creating a custom action to dynamically get a list of file extensions and filtering out ones I don't care about. Which one we go with all depends on what the impact of code being identified as "product" and "ignored". Thank you for your assistance in this matter.

[muiriswoulfe]

The sizing is based off the product code. The test code is used to create the check/warning indicator. Ignored code won't have any effect on either of those.

All your options sound valid, depending on what you ultimately want to achieve.

Let me know if you need additional clarification.