Automatically analyze your source code to surface issues and see if quality is improving or getting worse with the latest commit.
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)
Making the full code quality report available was just a step in solving the problem teams have when they are not able to easily view a full code quality report. We know that the current version of this feature will be more powerful if users can find data about specific files and errors which is why we are working on adding sort, filter and search to the code quality report next.
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 item is gitlab#29218 which allow c# developers to utilize the GitLab Code Quality features out of the box without having to customize their .gitlab-ci.yml files.
Showing code coverage delta in the MR widget (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.
In terms of moving the vision forward, gitlab#2766 (which creates a per-branch view for code quality) is an interesting approach. This brings code quality tracking out of the MR widget, and looks at how code quality is changing over a longer period of time in the context of a branch (or master.)
We also want to provide better support for .NET users of GitLab. gitlab#29218 adds support for more traditional Microsoft stack code coverage tools, making GitLab just as competent as Azure DevOps at showing code coverage.