このページの情報は古くなっている可能性があります。 最新の情報は 本家サイト でご確認ください。
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)
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 Code Quality report for default branch 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. The current Code Quality scanner has some limited scanning capaibility but the issue Support C# code quality results direction extends this to be more in line with scanning provided for other languages. Because CodeClimate does not yet have deep .NET support, we may need to build something ourselves.
An interesting suggestion from the CS team is to provide Instance wide code statistics, which is beyond just code quality but code quality could lead the way. We can see this being a view showing (for example) programming languages used, code quality statistics, and code coverage.
The most popular feature issue is Code quality report for default branch 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 reports.
A top problem identified by our internal customers is that the code quality MR Widget and Report lack context about if code quality issues were introduced in the current Merge Reqeust. This makes it hard to incorporate that extra data into a Code Review. By resolving the issue Show code quality notices on diffs/MRs we will help developers 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.