feat(package-rules): add matchRepositories / excludeRepositories

[setchy]

Changes

Add new matcher for repository patterns

Context

#23017

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

I thought we talked about matchRepositories allowing for full literal match or /.../ for regex. But do you think this is too inconsistent with other fields?

[setchy]

I thought we talked about matchRepositories allowing for full literal match or /.../ for regex. But do you think this is too inconsistent with other fields?

We did 😅

When implementing I noticed that the other matchers which support string/regex arrays follow a match*Patterns naming convention.

I'm happy to go either way

[secustor]

Features are on hold till v36 is released.

[viceice]

I thought we talked about matchRepositories allowing for full literal match or /.../ for regex. But do you think this is too inconsistent with other fields?

I like this idea, this would reduce the need for multiple matchers. we could do Minimatch by default and regex when starting and ending with slash.

[rarkins]

I thought we talked about matchRepositories allowing for full literal match or /.../ for regex. But do you think this is too inconsistent with other fields?

I like this idea, this would reduce the need for multiple matchers. we could do Minimatch by default and regex when starting and ending with slash.

@setchy can you make this change?

• regex if starting/ending in /
• minimatch otherwise (which supports exact matches too)

[secustor]

I thought we talked about matchRepositories allowing for full literal match or /.../ for regex. But do you think this is too inconsistent with other fields?

I like this idea, this would reduce the need for multiple matchers. we could do Minimatch by default and regex when starting and ending with slash.

@setchy can you make this change?

* regex if starting/ending in `/`

* minimatch otherwise (which supports exact matches too)

I would rather do this in separate PR changes this for all matchers.
If a single matcher has a different syntax, it will be confusing for users.

[setchy]

I thought we talked about matchRepositories allowing for full literal match or /.../ for regex. But do you think this is too inconsistent with other fields?

I like this idea, this would reduce the need for multiple matchers. we could do Minimatch by default and regex when starting and ending with slash.

@setchy can you make this change?

* regex if starting/ending in `/`

* minimatch otherwise (which supports exact matches too)

I would rather do this in separate PR changes this for all matchers. If a single matcher has a different syntax, it will be confusing for users.

Shall we raise a new issue / feature request. Add me as an assignee and I'll work on it as a fast follow this week.

[rarkins]

@CodiumAI-Agent

[CodiumAI-Agent]

PR Analysis

• 🎯 Main theme: Adding new matcher for repository patterns
• 🔍 Description and title: Yes
• 📌 Type of PR: Enhancement
• 🧪 Relevant tests added: Yes
• ✨ Minimal and focused: Yes, the PR is focused on adding a new feature of matching repositories and all changes are relevant to this feature.
• 🔒 Security concerns: No, the PR does not introduce any obvious security concerns. The new feature only involves matching repository names, which should not pose any security risks.

PR Feedback

• 💡 General PR suggestions: The PR is well-structured and follows good practices. The code is clean, and the new feature is well tested. The documentation has been updated to reflect the new changes, which is commendable.

• 🤖 Code suggestions:

  • relevant file: lib/util/package-rules/repositories.ts
    suggestion content: Consider adding more specific error handling for the isRegexAndMatches function. Currently, it catches any error and assumes it's due to an invalid regex. However, other errors could potentially occur. It would be beneficial to differentiate between an invalid regex error and other types of errors. [medium]

  • relevant file: lib/util/package-rules/repositories.ts
    suggestion content: In the isRegexAndMatches function, consider adding a comment explaining why the pattern is being massaged before being passed to the regEx function. This would improve code readability and maintainability. [medium]

  • relevant file: lib/util/package-rules/repositories.spec.ts
    suggestion content: Consider adding more edge cases to your tests, such as testing with empty strings, strings with special characters, and so on. This will ensure the robustness of your code. [medium]

  • relevant file: lib/config/types.ts
    suggestion content: Consider adding comments to describe the purpose of the new fields matchRepositories and excludeRepositories in the PackageRule interface. This will improve code readability. [medium]

How to use

Tag me in a comment '@CodiumAI-Agent' to ask for a new review after you update the PR.
You can also tag me and ask any question, for example '@CodiumAI-Agent is the PR ready for merge?'

[setchy]

@rarkins @viceice - anything further from your end re this? Seems general agreement to add minimatch caching separately

[rarkins]

Let's add the caching separately

[setchy]

Raised #23491 to track the minimatch caching feature request

[renovate-release]

🎉 This PR is included in version 36.18.0 🎉

The release is available on:

• GitHub release
• 36.18.0

Your semantic-release bot 📦🚀