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.
|Content Last Reviewed||
This direction page describes GitLab's plans for the Code Quality category, which helps you keep your code maintainable, idiomatic, and correct.
Everyone can contribute to where GitLab Code Quality goes next, and we'd love to hear from you. The best ways to participate in the conversation are to:
@gitlab-bot label ~"group::static analysis" ~"Category:Code Quality"so your issue lands in our triage workflow.
GitLab Code Quality helps you eliminate bugs, style violations, and mistakes before they're merged. These features can:
Code Quality shows quality findings in:
You can provide findings from any tool by saving a JSON report as a CI/CD artifact. This approach is great if you already use linters or other tools in your development process, or if you have custom organization-specific rules.
To learn more, check the Code Quality documentation.
Outside of the Code Quality Detection category, GitLab also offers other features that help you build quality software:
Ambitious vision: Code Quality is the single best way in GitLab to tell a code author and reviewer about a quality or linting problem in the diff they've submitted.
We believe we can accomplish this vision by shaping Code Quality into a flexible, open, community-oriented feature area. Adopting a more "pluggable" model should help us:
This approach is similar to the way that other products take standard coverage file formats. Within GitLab, similar examples include accepting the JUnit XML format for test reporting, and accepting CycloneDX reports for Software Bill of Materials information.
This approach does mean de-emphasizing the "automatic" scanning that has been a key part of how GitLab Code Quality has historically been presented and framed. We're still exploring ways that we could maintain this kind of automatic experience, but have become convinced that the current CodeClimate-based scanning system is not the way forward.
Our one-year focus includes two top priorities:
We intend to, at some point in 2023, announce the deprecation and upcoming End of Support for CodeClimate-based scanning. We currently plan to decide this timeline once we've evaluated how other tools can best be integrated directly with Code Quality; having that knowledge and documentation prepared will allow us to specify actionable steps to migrate away from CodeClimate-based scanning.
If you're considering whether or not to adopt Code Quality based on the upcoming changes to scanning, consider the following:
eslintdirectly and inject its report into the Code Quality system using the standard report format. We're working to collect examples of this in documentation, though we haven't completed this collection yet.
Code-QualityCI/CD template until it reaches formal, announced deprecation or End of Support status. If you chose to adopt CodeClimate-based scanning today, you will need to take action to update the scanner configuration later.
In the next 3 months, we are planning to:
We are currently working on:
Our recent work includes:
Check older release posts for our previous work in this area.
eslintdirectly, rather than mediating their configuration and operation through multiple layers of indirection.
valelinter used for product documentation.
markdownlintlinter, used in the GitLab internal handbook (accessible to team members only).
Team members have also proposed integrations to enforce design system migration.