Infrastructure/GitLab/CI/Static Code Analysis: Difference between revisions
Initial draft of the page |
|||
| Line 5: | Line 5: | ||
== Setting up == | == Setting up == | ||
The GitLab CI pipeline for each project is defined in project's <code>.gitlab-ci.yml</code> file, which must be placed in the top-level directory of the project's git repository. | |||
=== Frameworks, Applications and Extragear projects === | === Frameworks, Applications and Extragear projects === | ||
| Line 16: | Line 14: | ||
TODO | TODO | ||
== Customizing the static analyzer jobs == | == Customizing the static analyzer jobs == | ||
Revision as of 20:13, 6 September 2020
Motivation
Static code analysis is a helpful tool to improve and keep high level of code quality. Static code analyzer inspects the source code and looks for issues like wrong usage of some API, bugprone statements, potential performance issues and many others. The static analyzers available on our KDE instance of GitLab are clazy and clang-tidy. Since both of those analyzers are based on the clang C++ compiler, the issues the analyzers find are reported as regular compiler warnings.
Setting up
The GitLab CI pipeline for each project is defined in project's .gitlab-ci.yml file, which must be placed in the top-level directory of the project's git repository.
Frameworks, Applications and Extragear projects
TODO
Playground/Miscellaneous projects
TODO
Customizing the static analyzer jobs
TODO
Clazy
Intro TODO
Configuring Clazy
TODO
Supressing warnings
TODO
Clang-tidy
Intro TODO
Configuring Clang-tidy
TODO
Supressing warnings
TODO