Category Direction - Code Quality

1. You are here:
2. GitLab Direction
3. Product Stage Direction - Application Security Testing
4. Static Analysis group priorities
5. Category Direction - Code Quality

• Code Quality
• Overview
• Roadmap
• Effect of future scanning changes
• What we recently completed
• What is not planned right now
• Dogfooding
• Related categories

Code Quality

Stage	Secure
Maturity	Minimal
Content Last Reviewed	2024-08-26

This direction page describes GitLab's plans for the Code Quality category, which helps you keep your code maintainable, idiomatic, and correct.

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.

Overview

GitLab Code Quality shows quality problems in merge requests and quality reports to help code authors and reviewers eliminate bugs, style violations, and mistakes before they're merged.

Today, Code Quality offers two groups of features:

1. Scanning:
   • GitLab includes a CI/CD template that enables quality-related scans.
   • These scans are based on an open-source system called CodeClimate, which runs various "plugins" to do different types of code analysis.
   • CodeClimate plugins are almost entirely based on open-source quality tools like ESLint, but they are delivered as separate container images and run through a Docker-in-Docker system.
2. Result display: 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:

1. 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.
   • You can already provide findings from any tool by saving a JSON report as a CI/CD artifact.
   • Many tools (including many already used within GitLab) support the required output format, and we are collecting examples to make it easier to use those tools with Code Quality.
   • We published the deprecation announcement for this change in July 2024. End of Support and associated removals are scheduled for GitLab 18.0 (May 2026).
2. 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.

Effect of future scanning changes

If you're considering whether or not to adopt Code Quality based on the upcoming changes to scanning, consider:

• You can already adopt the new approach; it's supported today.
  • For example, you can use a tool like eslint directly and inject its report into the Code Quality system using the standard report format. Other examples are listed below.
  • We're working to collect examples of this in documentation, though we haven't completed this collection yet.
• You can still use the built-in Code-Quality CI/CD template until it reaches End of Support. If you chose to adopt CodeClimate-based scanning today, you will need to change your pipelines to use the new approach later.

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).
• Go linting, in security analyzers.
• CodeClimate-based analysis, gitlab-org/gitlab.

Team members have also proposed integrations to enforce design system migration.

Related categories

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

• Advanced security and compliance.
• CI/CD.
• Code coverage reports and test coverage visualization.
• Test case management.
• Unit test reports.