Fossa configuration file
FOSSA CLI's .fossa.yml configuration file
| Type | object |
|---|---|
| File match |
.fossa.yml
|
| Schema URL | https://catalog.lintel.tools/schemas/schemastore/fossa-configuration-file/latest.json |
| Source | https://raw.githubusercontent.com/fossas/fossa-cli/master/docs/references/files/fossa-yml.v3.schema.json |
Validate with Lintel
npx @lintel/lintel check.fossa.yaml specification for FOSSA CLI 2.x or greater
Properties
Specifies the version of configuration file. Versions 1 and 2 were used by CLI versions up until CLI 2.0.0 and are no longer supported.
CLI 2.x and greater only supports version 3.
Sets the endpoint that the CLI will send requests to. This field should only be modified if your FOSSA account lives on a different server than app.fossa.com.
This is most commonly needed with on-premise instances of FOSSA.
Sets the https://docs.fossa.com/docs/api-reference#api-tokens that is required for accessing the FOSSA API and uploading data (e.g. fossa analyze) or retrieving information (e.g. fossa test) about a project.
The project fields allow you to configure settings for the project you are interacting with through the FOSSA API.
12 nested properties
The project Locator defines a unique ID that the FOSSA API will use to reference this project within FOSSA. The project locator can be found in the UI on the project Settings page listed as the Project Locator underneath the Project Title setting.
The project ID defines a unique ID that the FOSSA API will use to reference this project within your organization. The project ID is a specific portion of the project locator and can be found in the UI on the project Settings page listed as the Project Locator underneath the Project Title setting.
By default, it will use git remote origin url as project id if it's git repository. If it does not recognize version control system (vcs), project directory's name will be used.
The name field sets the projects visible name in the FOSSA dashboard. By default, this will be set to the project's ID.
The name of the team in your FOSSA organization to associate this project with.
A list of team names in your FOSSA organization to associate this project with.
The name of the policy in your FOSSA organization to associate this project with. Mutually excludes project.policyId.
The id of the policy in your FOSSA organization to associate this project with. Mutually excludes project.policy.
An external link that will appear in the FOSSA UI for this specific project.
The URL of your project that will appear in FOSSA. This URL is intended to be the URL to the repository of this project.
The Jira Project Key to associate with your project for improved issue triage. Refer to https://docs.fossa.com/docs/atlassian-jira#linking-fossa-projects-to-jira-projects for more information.
The name: and release: of the release group's release to add your project to in the FOSSA dashboard. If you choose to associate a project with a release group, you must supply both name and release.
2 nested properties
The name of release group.
The release associated with the release group
A list of labels that are assigned to the project
The releaseGroup field allows you to configure settings for the release group you are interacting with through the FOSSA API.
7 nested properties
The title of the release group which can be seen in the FOSSA dashboard.
The release associated with the release group.
The name of the license policy associated with the release group.
The name of the security policy associated with the release group.
The name of the quality policy associated with the release group.
A list of team names that are associated with the release group.
The telemetry fields are used to configure telemetry data collection and it's destination.
2 nested properties
project branch is an optional setting used for organizing project revisions in the FOSSA UI. The branch field is intended to function similar to how Git defines a branch.
The commit is used to identify a specific scan for a project (determined by project.id). This is intended to be used identically to how Git treats commit hashes. If not provided, cli will parse current HEAD state from .git directory. If project does not have version control system, unix timestamp will be used.
the vendoredDependencies fields allow you to configure vendored dependency scans. Vendored dependency scans are described in https://github.com/fossas/fossa-cli/blob/master/docs/features/vendored-dependencies.md
3 nested properties
If true, forces a re-scan of all vendored dependencies on every run. If false or not present, then we do not re-scan vendored dependencies that have been previously scanned. A vendored dependency has been previously scanned if a dependency with the same name and version has already been scanned by your organization. If no version is provided, then any change in the files being scanned will result in a rescan.
licenseScanPathFilters allows you to filter which files are scanned when doing a CLILicenseScan. This setting does not apply if you use the ArchiveUpload method of scanning vendoredDependencies.
2 nested properties
A list of globs that will be used to filter paths. If there are any entries in the only list, then only paths that match one or more of the globs in the only list will be scanned for licenses.
A list of globs that will be used to filter paths. If there are any entries in the exclude list, then paths that match any of the exclude entries will not be scanned for licenses.
Controls the Reachability computation functionality
1 nested properties
Manually specify the list of JAR files output by each discovered Maven or Gradle project
Ignore custom-license scan configurations for your organization. These configurations are defined in the Integrations section of the Admin settings in the FOSSA web app.
The targets filtering allows you to specify the exact targets which be should be scanned.
3 nested properties
The list of only targets that should be scanned.
The list of exclude targets which should be excluded from scanning. The targets listed in the exclude section will override the targets listed in the only sections.
This feature is used most effectively to remove specific targets from a directory.
If set to true, all manifest-based strategies for discovering targets will be skipped. This has the effect of only searching dependencies explicitly specified in fossa-deps.yml. This setting will override any target filters or path filters.
The paths filtering section allows you to specify which paths should be scanned and which should not. The paths should be listed as their location from the root of your project.
2 nested properties
The list of paths to only allow scanning within.
The list of paths to exclude from scanning in your directory.
2 nested properties
The list of scopes to only allow scanning in your maven project.
The list of scopes to exclude from scanning in your maven project.
Definitions
The project fields allow you to configure settings for the project you are interacting with through the FOSSA API.
The project Locator defines a unique ID that the FOSSA API will use to reference this project within FOSSA. The project locator can be found in the UI on the project Settings page listed as the Project Locator underneath the Project Title setting.
The project ID defines a unique ID that the FOSSA API will use to reference this project within your organization. The project ID is a specific portion of the project locator and can be found in the UI on the project Settings page listed as the Project Locator underneath the Project Title setting.
By default, it will use git remote origin url as project id if it's git repository. If it does not recognize version control system (vcs), project directory's name will be used.
The name field sets the projects visible name in the FOSSA dashboard. By default, this will be set to the project's ID.
The name of the team in your FOSSA organization to associate this project with.
A list of team names in your FOSSA organization to associate this project with.
The name of the policy in your FOSSA organization to associate this project with. Mutually excludes project.policyId.
The id of the policy in your FOSSA organization to associate this project with. Mutually excludes project.policy.
An external link that will appear in the FOSSA UI for this specific project.
The URL of your project that will appear in FOSSA. This URL is intended to be the URL to the repository of this project.
The Jira Project Key to associate with your project for improved issue triage. Refer to https://docs.fossa.com/docs/atlassian-jira#linking-fossa-projects-to-jira-projects for more information.
The name: and release: of the release group's release to add your project to in the FOSSA dashboard. If you choose to associate a project with a release group, you must supply both name and release.
2 nested properties
The name of release group.
The release associated with the release group
A list of labels that are assigned to the project
The telemetry fields are used to configure telemetry data collection and it's destination.
project branch is an optional setting used for organizing project revisions in the FOSSA UI. The branch field is intended to function similar to how Git defines a branch.
The commit is used to identify a specific scan for a project (determined by project.id). This is intended to be used identically to how Git treats commit hashes. If not provided, cli will parse current HEAD state from .git directory. If project does not have version control system, unix timestamp will be used.
The revision fields are used to help FOSSA differentiate between one upload for a project and another, just as GitHub uses commit hashes and branch names.
project branch is an optional setting used for organizing project revisions in the FOSSA UI. The branch field is intended to function similar to how Git defines a branch.
The commit is used to identify a specific scan for a project (determined by project.id). This is intended to be used identically to how Git treats commit hashes. If not provided, cli will parse current HEAD state from .git directory. If project does not have version control system, unix timestamp will be used.
Target (package manager)
Associated path with target type (if any)
Experimental preferences with fossa cli.
Gradle preferences for all targets
1 nested properties
Configurations to only include in analysis (by default excludes any other configurations not listed)
the vendoredDependencies fields allow you to configure vendored dependency scans. Vendored dependency scans are described in https://github.com/fossas/fossa-cli/blob/master/docs/features/vendored-dependencies.md
If true, forces a re-scan of all vendored dependencies on every run. If false or not present, then we do not re-scan vendored dependencies that have been previously scanned. A vendored dependency has been previously scanned if a dependency with the same name and version has already been scanned by your organization. If no version is provided, then any change in the files being scanned will result in a rescan.
licenseScanPathFilters allows you to filter which files are scanned when doing a CLILicenseScan. This setting does not apply if you use the ArchiveUpload method of scanning vendoredDependencies.
2 nested properties
A list of globs that will be used to filter paths. If there are any entries in the only list, then only paths that match one or more of the globs in the only list will be scanned for licenses.
A list of globs that will be used to filter paths. If there are any entries in the exclude list, then paths that match any of the exclude entries will not be scanned for licenses.
defines a search for a custom license or a keyword.
A regular expression used to find a keyword or custom license
The name of the keyword or custom license found by the regular expression defined in matchCriteria
The releaseGroup field allows you to configure settings for the release group you are interacting with through the FOSSA API.
The title of the release group which can be seen in the FOSSA dashboard.
The release associated with the release group.
The name of the license policy associated with the release group.
The name of the security policy associated with the release group.
The name of the quality policy associated with the release group.
A list of team names that are associated with the release group.