Automatically analyze your static source code to surface issues and see if quality is improving or getting worse with the latest commit. Our vision for Code Quality is to provide actionable data across an organization to empower users to make quality visible with every commit and in every release.
Interested in joining the conversation for this category? Please join us in the issues where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
This page is maintained by the Product Manager for Testing, James Heimbuck (E-mail)
Moving the Code Quality Merge Request Widget to Core is the next item for the Code Quality category. As we think about Code Quality and displaying how a Merge Request is changing that value it was clear that this feature will be championed by the individual developer. This feature belongs in the GitLab Tier targeted at that user, Core.
To move closer to our long term Vision of a Code Quality Dashboard we need to first ensure that users are only looking at Code Quality alerts that matter to them so they do not lose the important notices in a thousand point report. To enable that we will first allow users to customize their rules and not show notices for rules marked ignore.
This category is currently at the "Minimal" maturity level, and our next maturity target is "Viable" (see our definitions of maturity levels). Key deliverables to achieve this are:
We may find in research that only some of these issues are needed to move the vision for this category forward. The work to move the vision is captured and being tracked in this epic.
Azure DevOps does not offer in-product quality testing in the same way we do with CodeClimate, but does have a number of easy to find and install plugins in their marketplace that are both paid and free. Their SonarQube plugin appears to be the most popular, though it seems to have some challenges with the rating.
In order to remain ahead of Azure DevOps, we should continue to push forward the feature capability of our own open-source integration with CodeClimate. Issues like gitlab-ee#2766 (per-branch view for how code quality progresses over time) moves both our vision forward as well as ensures we have a high quality integration in our product. To be successful here, though, we need to support formats Microsoft-stack developers use: gitlab#29218 gets the ball rolling. Because CodeClimate does not yet have deep .NET support, we may need to build something ourselves.
An interesting suggestion from the CS team is gitlab#8406, which is beyond just code quality but code quality could lead the way. This item introduces instance wide code statistics, showing (for example) programming languages used, code quality statistics, and code coverage.
The most popular feature issue is gitlab#2766 which will let developers get information about code quality issues in the default branch outside of a pipeline or MR context.
Another top customer priority is to resolve the performance issues in parsing large code quality items in gitlab#2737
Sharing line by line code quality data from a report (gitlab#2526) is a useful feature for internal users that will help us make better decisions about if a merge request should be merged, or if it needs further refinement.
Our vision for Code Quality is for it to become another rich signal of confidence for users of GitLab. This will be not just a signal of the quality of a change but one of many inputs like Code Coverage to be able to view a project at a high level and make decisions about what code needs attention, additional tests or refactoring, to bring it up to the quality requirements of the group. This long term vision is captured in the issues Instance wide code statistics and Code Quality Dashboard.