Defining matching patterns
SonarQube Cloud supports a set of path-matching patterns to help you include and exclude files from analysis. This page outlines the patterns that work.
Defining matching patterns for files
To define path-matching patterns, you can use the following wildcards:
*
matches zero or more characters (not including the directory delimiter,/
).**
matches zero or more directory segments within the path.?
matches a single character (not including the directory delimiter,/
).
A file path definition is either relative to the sonar.projectBaseDir property, which is by default the directory from which the analysis was started, or absolute. See Analysis parameters for more information.
The table below shows path-matching pattern examples.
Matching pattern
Definition
**/*.css
<anyDirectory>/<anyFileName>.css
**/*Bean.java
<anyDirectory>/<anyString>Bean.java
Example: org/sonar.api/MyBean.java
**/*Bean?.java
<anyDirectory>/<anyString>Bean<singleCharacter>.java
Example: org/sonar.api/MyBean1.java
org/sonar/*
org/sonar/<anyFile>
org/sonar/**
or
org/sonar/**/*
org/sonar/<anyDirectory>/<anyFile>
Example: org/sonar/api/test/Bean.java
Defining matching patterns for coding rules
To define matching patterns for coding rules, use the following syntax:
<ruleRepository>:<searchString>
Where:
ruleRepository: is the identifier of the rule repository Examples: SonarQube java (identifier: java) or Security SonarAnalyzer PHP (identifier: phpsecurity), etc. You can use the wildcard pattern * (any string) to define the rule repository.
searchString: is any search string present in the rule key or in the rule name
The matching pattern means that any rule:
of the specified repository
whose name or key contains the specified search string
is a match.
Last updated
Was this helpful?