Expand pattern matching to filename & extension

[JosephVolosin]

This PR is the UI implementation of the ValueSchema change here: NASA-AMMOS/plandev-actions#21

To handle the change of pattern to extensionPattern and the inclusion of filenamePattern, the if logic is slightly changed and a new function that preforms a regex search is added.

For more context, see this issue: #1872

[duranb]

Can you provide some unit tests for this function?

[JosephVolosin]

Can you provide some unit tests for this function?

Added!

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[duranb]

Can you provide some unit tests for this function?

Added!

Thank you! Is there a case where the pattern needs to match multiple parts of the name? For example, is there a naming convention where the filename could be seq_1_nav.seq and the pattern wants to match seq_ and _nav without the number? Is it also okay that this can potentially ignore the file extension?

[JosephVolosin]

Can you provide some unit tests for this function?

Added!

Thank you! Is there a case where the pattern needs to match multiple parts of the name? For example, is there a naming convention where the filename could be seq_1_nav.seq and the pattern wants to match seq_ and _nav without the number? Is it also okay that this can potentially ignore the file extension?

I think multiple parts is a valid case. With this change, a pattern like this seq_.+?(?=_)_nav should work and properly match files with both seq and nav, with varying content in-between.

I also think its okay that this can potentially ignore the file extension as there's another option specifically for the extension, but maybe we should just condense those two to the same option so it's more clear?

[duranb]

I think multiple parts is a valid case. With this change, a pattern like this seq_.+?(?=_)_nav should work and properly match files with both seq and nav, with varying content in-between.

I believe this would require a change that wraps the string in a RegExp object before passing it into search(). Would you mind also adding a test case for that as well?

I also think its okay that this can potentially ignore the file extension as there's another option specifically for the extension, but maybe we should just condense those two to the same option so it's more clear?

No, I think the separation is good as is. It was just more for me to understand.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud