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.
