Category Direction - Code Quality

The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.

Overview
Roadmap
What we recently completed
What is not planned right now
Dogfooding
Related categories
Get involved
Page updates

This direction page describes GitLab's plans for the Code Quality category.

Overview

GitLab Code Quality helps code authors and reviewers eliminate bugs, style violations, and other mistakes before they're merged.

Code Quality results are processed and displayed in an MR widget, in the MR Changes view, in a pipeline report, and in a project-level quality summary.

To learn more, check the Code Quality documentation.

Roadmap

Looking forward:

We are deprecating and removing CodeClimate-based scanning and moving toward a flexible, open, community-oriented design that emphasizes using quality tools directly as CI jobs.
- To learn more about the change, please see the following public resources:
  - Deprecation announcement
  - Restructured Code Quality documentation explaining the options for scanning
  - List of documented integrations (more MRs welcome!)
  - Migration cross-reference in documentation
- Team members have access to additional resources, including enablement training, in the Field Guide for this change, on Highspot.
- We published the deprecation announcement for this change in July 2024. End of Support and associated removals are scheduled for GitLab 18.0 (May 2025).
We are not currently planning improvements in result display, and we do not expect to make significant investments in this area in the next 12 months.

What we recently completed

Check release posts for our previous work in this area.

What is not planned right now

Proprietary quality analysis: We currently plan to focus on integrating with existing quality tools instead of creating our own quality-focused analyzer.
- We believe that improving the experience for users of all quality tools—including open-source linters, third-party products, and custom tools—delivers value sooner, and doesn't detract from our ability to bring a proprietary tool to market later.
Mixing quality and security: We aren't planning to blur the lines between security and quality findings. We believe it's valuable to keep quality and security findings distinct, since these tools and processes are maintained by different personas and are subject to different organizational requirements.
- For example, while quality tools and their rules are typically managed by software engineering departments, security tools (and rules about how to handle security findings) typically involve security professionals and are monitored for adherence to compliance controls.
- However, users should see a consistent user experience for quality and security findings, and we shouldn't have to inefficiently build each workflow feature twice either. We will consider ways to align the experience between quality and security in the future.
Modifications to CodeClimate: We don't believe we have an effective path forward to modify CodeClimate or its plugins. This conclusion is based on the collective weight of a mix of factors:
- We don't have a clear technical path toward removing the Docker-in-Docker requirement, despite more than one investigation.
- The AGPL license used for most CodeClimate core components and plugins makes contributions and operations more difficult for GitLab and for customers.
- Many existing plugins do not have active communities and do not receive regular updates.
- The workflow for typical development tool usage includes development teams updating and maintaining their project configurations to use tools in many contexts, rather than just in CI. (See UX research.)
- It is simpler and more efficient to run tools like eslint directly, rather than mediating their configuration and operation through multiple layers of indirection.
- Mediating access through CodeClimate doesn't provide unique capabilities: the underlying tools for each official CodeClimate plugin are each available to use directly.

Dogfooding

GitLab teams collaborate more efficiently by using Code Quality to surface issues during code review. Team members have integrated:

The vale linter for product documentation.
The markdownlint, vale, and hugolint linters, and a custom linter, in the GitLab internal handbook (accessible to team members only).
golangic-lint in security analyzers.
ESLint for JavaScript in gitlab-org/gitlab.
Stylelint for CSS in gitlab-org/gitlab-ui.
markdownlint2-cli in the public handbook.
A custom linter in the public handbook.

Outside of the Code Quality category, GitLab also offers other features that help you build quality software:

Get involved

You can contribute to where GitLab Code Quality goes next by:

Commenting or contributing to existing Code Quality issues in the public gitlab-org/gitlab issue tracker.
If you don't see an issue that matches, filing a new issue.
- Post a comment that says @gitlab-bot label ~"group::static analysis" ~"Category:Code Quality" so your issue lands in our triage workflow.
If you're a GitLab customer, discussing your needs with your account team.

Page updates


Stage	Application Security Testing
Content Last Reviewed	`2025-02-06`