You can change Sigrid's configuration for your project, to make Sigrid's feedback as useful and actionable as possible. We call this configuration "the scope".
By default, Sigrid will try to automatically detect the technologies you use, the component structure, and files/directories that should be excluded from the analysis. However, you can override this standard configuration with your project-specific configuration. To do this, create a file called sigrid.yaml and add it to the root of your repository. When you merge changes to sigrid.yaml, Sigrid will pick up the new configuration and apply it to subsequent scans.
The following example shows a typical example of the sigrid.yaml configuration file:
component_depth: 1
exclude:
- ".*/simulator/.*"
languages:
- java
- python
- typescript
| Field | Required | Description |
|---|---|---|
model |
No | Version of the SIG quality model that should be used to analyze your project. Default is latest model version. |
Sigrid will exclude common patterns by default. For example, directories like build, dist, and target typically contain build output and are not part of the source code. Directories like node_modules contain open source libraries and are not part of the application's own source code. Those directories are therefore ignored during the analysis.
It is possible to extend this list with project-specific files and directories that should also be excluded. The exclude section in the YAML file contains a list of regular expressions for paths to ignore. For example, .*[.]out[.]js will exclude all files with a name ending in .out.js from the analysis. Adding .*/simulator/.* will exclude everything in the directory simulator.
Note that it is not necessary to exclude files and directories that would not be analyzed anyway.
See the list of supported technologies for the names that can be used inside the languages section of the YAML file.
Component detection is based on the project's directory structure. What "components" mean depends on the technology. In Java, components are usually based on Maven modules. In C, components are often simply the project's top-level directories.
Components can be defined in two ways. The simple option is to simply base the components on directory depth. The following example will use the project's top-level directories as components.
component_depth: 1
In some projects, using directory depth will not accurately reflect the actual component structure. The more advanced option allows you to define components explicitly:
components:
- name: "Back-end"
include:
- ".*[.]java"
- name: "Front-end"
include:
- ".*[.]ts"
In this example, regular expressions are used to define what files and directories belong to each component. The syntax is identical to the patterns used in the exclude section.
Feel free to contact SIG's support department for any questions or issues you may have after reading this document, or when using Sigrid or Sigrid CI. Users in Europe can also contact us by phone at +31 20 314 0953.