GitLab is the open DevOps platform. It’s widely used to plan, develop, test, secure, and collaborate throughout the software development lifecycle.
By configuring GitLab into Cortex, you’ll be able to:
Import GitLab services
View commits within the context of the service timeline
Create Scorecard rules specific to GitLab
To get started, see our documentation for adding GitLab to Cortex.
Service import
Once you’ve configured GitLab in Cortex, you’ll be able to import your GitLab services into Cortex. It’s simple - just create a new service and you’ll see the list of services. You can then select which you want to import into Cortex.
GitLab commits in the service timeline
Each service has a timeline - It combines your Git commits for the service with other events, such as Pagerduty incidents, Sentry issues, and Snyk vulnerabilities. This is particularly powerful during an incident when you want to see various events in order and need to quickly find the root cause of the problem.
If you just want to see the list commits, you can also look at the Git tab.
Scorecard integration
Additionally, you’ll also be able to enforce best practices for development maturity in Scorecards through the various Git rules that we have. You can check:
If service has Git repo attached
If file exists in Git
If Git file contents match a regular expression
How many required approvals are needed to merge
Percentage of successful builds
If repository has a cortex.yaml file
Has CI pipeline attached
Git commit freshness
Number of vulnerabilities
Number of vulnerabilities for custom filters like severity level and scan type
These rules can help ensure that teams are confirming basic development best practices, like code coverage, checking in lockfiles, READMEs, package versions, as well as ownership and other types of rules using other integrations. Some example rules for such a Scorecard are:
owners.count > 2 - Catch organizational risk by detecting orphaned services
git.fileExists(“package-lock.json”)- Developers should be checking in lockfiles to ensure repeatable builds.
sonarqube.metric(“coverage”) > 80.0 - Set a threshold that’s achievable, so there’s an incentive to actually try. This also serves secondarily as a check that the service is hooked up to Sonarqube and reporting frequently
git.lastCommit.freshness < duration(“P30D”)- Services that are committed to infrequently, counterintuitively, are actually at more risk. This is because people who are familiar with the service may leave the team, tribal knowledge accumulates, and from a technical standpoint, the service may be running old/outdated versions of your platform tooling.
git.fileExists(*Test.java”)- Use a wildcard search to make sure there are unit tests enabled
git.numRequiredApprovals >= 1 - Ensure that a rigorous PR process is in place for the repo, and PRs must be approved by at least one user before merging
git.fileContents(“circleci/config.yml”).matches(“.*npm test.*”) - Enforce that a CI pipeline exists, and there is a testing step defined in the pipeline
git.vulnerabilities(severity=["CRITICAL"], scan_types=["SAST"]) < 5 - Catch critical vulnerabilities from different types of scans.
In our reports view, you’ll be able to get a quick overview of how all services are doing. If you notice that a lot of services are failing, worry not! You can create an Initiative and prioritize certain rules to be focused on. Cortex will send each service owner their action items as the target date approaches, making it extremely easy to set attainable goals and accelerate progress towards best practices.
Start using Cortex & GitLab today
Using GitLab within Cortex will allow you to set best standards for development maturity and monitor service status in real time. Visit our documentation to integrate GitLab with Cortex. If you're new to Cortex, set up a demo with our team to get started.
