Similar to the Source Control Management (SCM) integration plugin, the GitLab integration plugin for Soundcheck provides out-of-box integration with GitLab by leveraging Backstage’s GitLab integration to implement collection of facts from GitLab repositories. The purpose of the GitLab integration plugin is to provide GitLab-specific fact collection (like branch protections), while the SCM integration plugin provides the collection of facts based on project content. The GitLab integration plugin supports the collection of the following facts:Documentation Index
Fetch the complete documentation index at: https://backstage.spotify.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
Prerequisites
Configure GitLab integration in Backstage
Integrations are configured at the root level ofapp-config.yaml. Here’s an example configuration for GitLab:
Add the GitlabFactCollector to Soundcheck
GitLab integration for Soundcheck is not installed by default. It must be manually installed and configured for the GitLab Fact Collector to work. First, add the@spotify/backstage-plugin-soundcheck-backend-module-gitlab package:
packages/backend/src/index.ts file:
packages/backend/src/index.ts
Plugin Configuration
The collection of facts is driven by configuration. To learn more about the configuration, jump to the Defining GitLab Fact Collectors section. GitLab Fact Collector can be configured via YAML or No-Code UI. If you configure it via both YAML and No-Code UI, the configurations will be merged. It’s preferable to choose a single source for the Fact Collectors configuration (either No-Code UI or YAML) to avoid confusing merge results.No-Code UI Configuration Option
- Make sure the prerequisite Configure GitLab integration in Backstage is completed and GitLab instance details are configured.
-
To enable the GitLab Integration, go to
Soundcheck > Integrations > GitLaband click theConfigurebutton. To learn more about the No-Code UI config, see the Configuring a fact collector (integration) via the no-code UI.

YAML Configuration Option
-
Create a
gitlab-facts-collectors.yamlfile in the root of your Backstage repository and fill in all your GitLab Fact Collectors. A simple example GitLab Fact Collector is listed below.Note: this file will be loaded at runtime along with the rest of your Backstage configuration files. Therefore, make sure that it’s available in deployed environments in the same way as yourgitlab-facts-collectors.yamlapp-config.yamlfiles are. -
Add a soundcheck collectors field to
app-config.yamland reference the newly createdgitlab-facts-collectors.yamlapp-config.yaml
Rate Limiting (Optional)
This fact collector can be rate limited in Soundcheck using the following configuration:app-config.yaml
Defining GitLab Fact Collectors
This section describes the data shape and semantics of GitLab Fact Collectors.Overall Shape Of A GitLab Fact Collector
The following is an example of a descriptor file for a GitLab Fact Collector:frequency [optional]
The frequency at which the collector should be executed. Possible values are either a cron expression { cron: ... } or HumanDuration.
This is the default frequency for each fact type.
Example:
initialDelay [optional]
The amount of time that should pass before the first invocation happens. Possible values are either a cron expression { cron: ... } or HumanDuration.
This is the default initial delay for each fact type.
Example:
batchSize [optional]
The number of entities to collect facts for at once. Optional, the default value is 1.
Note: Fact collection for a batch of entities is still considered as one hit towards the rate limits
by the Soundcheck Rate Limiting engine, while the actual number of hits
will be equal to the batchSize.
Example:
filter [optional]
A filter specifying which entities to collect the specified facts for. Matches the filter format used by the Catalog API.
This is the default filter for each fact type.
Example:
exclude [optional]
Entities matching this filter will be skipped during the fact collection process. Can be used in combination with filter. Matches the filter format used by the Catalog API.
cache [optional]
If the collected facts should be cached, and if so for how long. Possible values are either true or false or a nested { duration: HumanDuration } field.
This is the default cache config for each fact type.
Example:
collects [required]
An array describing which facts to collect and how to collect them. See below for details about the configuration of fact collection for each fact type.
-
The name of the fact to be collected (must be unique within GitLab collector).factName[optional]- Minimum length of 1
- Maximum length of 100
- Alphanumeric with single separator instances of periods, dashes, underscores, or forward slashes
typevalue (see below). -
The type of the collector (e.g.type[required]branch_protections,project_details,project_languages). -
The frequency at which the fact collection should be executed. Possible values are either a cron expressionfrequency[optional]{ cron: ... }or HumanDuration. If provided, it overrides the default frequency provided at the top level. If not provided, it defaults to the frequency provided at the top level. If neither collector’s frequency, nor default frequency is provided, the fact will only be collected on demand. -
The amount of time that should pass before the first invocation happens. Possible values are either a cron expressioninitialDelay[optional]{ cron: ... }or HumanDuration. If provided, it overrides the default initial delay provided at the top level. If not provided, it defaults to the initial delay provided at the top level. If neither collector’s initial delay, nor default initial delay is provided, the fact will be collected with no initial delay. -
The number of entities to collect facts for at once. Optional, the default value is 1. If provided it overrides the default batchSize provided at the top level. If not provided it defaults to the batchSize provided at the top level. If neither collector’s batchSize nor default batchSize is provided the fact will be collected for one entity at a time. Note: Fact collection for a batch of entities is still considered as one hit towards the rate limits by the Soundcheck Rate Limiting engine, while the actual number of hits will be equal to thebatchSize[optional]batchSize. Example: -
A filter specifying which entities to collect the specified facts for. Matches the filter format used by the Catalog API. If provided, it overrides the default filter provided at the top level. If not provided, it defaults to the filter provided at the top level. If neither collector’s filter, nor default filter is provided, the fact will be collected for all entities. See filters for more details.filter[optional] -
Entities matching this filter will be skipped during the fact collection process. Can be used in combination with filter. Matches the filter format used by the Catalog API.exclude[optional] -
If the collected facts should be cached, and if so for how long. Possible values are eithercache[optional]trueorfalseor a nested{ duration:HumanDuration}field. If provided, it overrides the default cache config provided at the top level. If not provided, it defaults to the cache config provided at the top level. If neither collector’s cache nor default cache config is provided, the fact will not be cached.
Collecting Branch Protections Fact
Thebranch_protections fact contains information about configured branch protections for a given branch in a GitLab project.
Shape of A Branch Protections Fact Collector
The shape of abranch_protections Fact Collector extends the Overall Shape Of A GitLab Fact Collector (restriction: type: branch_protections).
Additional fields:
-
The branch to collect the fact from. If not provided, defaults to the project’s default branch. If provided, collected fact scope will be set to the configured branch name.branch[optional]
branch_protections Fact Collector configuration:
Shape of A Branch Protections Fact
The shape of abranch_protections Fact is based on the Fact Schema.
For a description of the data collected regarding branch protection, refer to the GitLab API documentation.
The following is an example of the collected branch_protections fact:
Shape of A Branch Protections Fact Check
The shape of abranch_protections Fact Check matches the Shape of a Fact Check.
The following is an example of the branch_protections fact checks:
Collecting Project Details Fact
Theproject_details fact contains information about a GitLab project.
Shape of A Project Details Fact Collector
The shape of aproject_details Fact Collector matches the Overall Shape Of A GitLab Fact Collector (restriction: type: project_details).
The following is an example of the project_details Fact Collector configuration:
Shape of A Project Details Fact
The shape of aproject_details Fact is based on the Fact Schema.
For a description of the data collected about project, refer to the GitLab API documentation.
The following is an example of the collected project_details fact:
Shape of A Project Details Fact Check
The shape of aproject_details Fact Check matches the Shape of a Fact Check.
The following is an example of the project_details fact checks:
Collecting Project Languages Fact
Theproject_languages fact contains information about languages used within a GitLab project (percentage value).
Shape of A Project Languages Fact Collector
The shape of aproject_languages Fact Collector matches the Overall Shape Of A GitLab Fact Collector (restriction: type: project_languages).
The following is an example of the project_languages Fact Collector configuration:
Shape of A Project Languages Fact
The shape of aproject_languages Fact is based on the Fact Schema.
For a description of the data collected about project languages, refer to the GitLab API documentation.
The following is an example of the collected project_languages fact:
Shape of A Project Languages Fact Check
The shape of aproject_languages Fact Check matches the Shape of a Fact Check.
The following is an example of the project_languages fact checks: