GitLab is a Git-based VCS that has a Cloud and Self-Hosted option. You can use GitLab to drive insights into values such as:
- Git repository details (commit history, contributors)
- Scorecard rules
If you do not see the Settings page you're looking for in the sidebar, you likely don't have the proper permissions and need to contact your admin.
GitLab has multi account support - entities can be tagged across different GitLab organizations, instances, and credentials.
Each GitLab configuration requires a GitLab Personal Token with the
read_api scope and an alias. We use the alias to correlate the instance you want to use with the application registrations for various entities. There is also a default configuration used by registrations without an alias listed. You can edit aliases and the default configuration under Settings → GitLab.
If using the Scaffolder, you'll need the full
We route our requests through a static IP address. Reach out to support at email@example.com to receive details about our static IP. If you're unable to directly whitelist our static IP, you can route requests through a secondary proxy in your network that has this IP whitelisted, and have that proxy route traffic to your GitLab instance.
In order to use GitOps with GitLab, a webhook must be created. Setup steps for webhooks can be found here.
By specifying the
x-cortex-git field in your Cortex Catalog Descriptor, you'll be able to see Git information in the entity page, including the top language, recent commits, and top contributors.
basepath: myService # optional
alias: myApp # optional
namespace/repo as defined in GitLab
|If the entity is in a monorepo (e.g. in a subdirectory), use this field to define the subdir
|Alias is optional and only relevant if you have opted into multi account support
You can define the following block in your Cortex Catalog Descriptor to add your GitLab groups.
Team name should match the group name in GitLab.
- type: group
name: Group Name
description: This is a description for this owner # optional