{"id":114768,"date":"2021-02-11T12:49:11","date_gmt":"2021-02-11T11:49:11","guid":{"rendered":"https:\/\/blog.jetbrains.com\/?post_type=idea&p=114768"},"modified":"2022-09-11T17:17:01","modified_gmt":"2022-09-11T16:17:01","slug":"early-access-program-for-qodana-a-new-product-that-brings-the-smarts-of-jetbrains-ides-into-your-ci-pipeline","status":"publish","type":"idea","link":"https:\/\/blog.jetbrains.com\/fr\/idea\/2021\/02\/early-access-program-for-qodana-a-new-product-that-brings-the-smarts-of-jetbrains-ides-into-your-ci-pipeline","title":{"rendered":"Early Access Program for Qodana, a New Product That Brings the \u201cSmarts\u201d of JetBrains IDEs Into Your CI Pipeline"},"content":{"rendered":"

\"qodana-banner\"<\/p>\n

JetBrains IDEs are well known for their ability to understand code. They can track declarations, check references and types, and collect possible execution paths. Thanks to all this static analysis<\/strong>, you are able to rename and move things around safely, get appropriate code completion, and get warned with a message saying \u201chey, this<\/em> won’t run\u201d from the code inspection<\/strong> if you are adding something that won\u2019t work into your code.<\/p>\n

Having all this while you are working in the editor is extremely helpful, but modern CI-centric workflows require having a reliable quality gate in your build pipeline. The multitude of tools being actively developed and used in this area clearly support this statement.<\/p>\n

It was technically possible to run JetBrains IDE inspections<\/em> for the whole project in headless batch mode well before the CI era. However, integrating an IDE into the CI pipeline as a typical linter proved difficult.<\/p>\n

<\/p>\n

Qodana is the solution<\/h2>\n

Qodana comprises two main parts: a nicely packaged GUI-less IntelliJ IDEA engine tailored for use in a CI pipeline as a typical \u201clinter\u201d tool, and an interactive web-based reporting UI.<\/p>\n

It makes it easy to set up workflows to get an overview of the project quality, set quality targets, and track progress on them. You can quickly adjust the list of checks applied for the project and include or remove directories from the analysis.<\/p>\n

\"qodana-exclude-source-directory\"<\/p>\n

The example above shows how to exclude a source directory or inspection category from the analysis. Another way to configure this is to use the qodana.yaml<\/code> file. See the details in our user guide<\/a>.<\/p>\n

Demo of popular projects<\/h2>\n

We\u2019ve created a playground for you to see Qodana in action for popular projects: OkHttp, Guava, ZXing, and a couple of others. Although the code in these projects may run on millions of machines daily, with the help of Qodana you can easily see what can be improved. It doesn’t mean that the code is bad, it just means that the technologies are evolving, the surroundings are changing, and we need to keep up.<\/p>\n

\"qodana-ui-overview\"<\/p>\n

In the example report above that was run on the ZXing project, you can see that there are 5 cases in 5 files where the condition has always the same result. You can click Open in IDE<\/em> and apply quick-fixes to this code. As a result, the next developer who works with these files will be able to spend less time trying to work out why this condition is included and whether it is redundant or not.<\/p>\n

To open the sandbox playground, use the following link https:\/\/qodana.teamcity.com\/login.html<\/a>\u00a0and select the \u201clogin as guest\u201d option to explore the UI integrated into the JetBrains cloud CI, TeamCity. You can use the Qodana tab<\/a> to see what problems it found, browse the list of inspections that it ran, and try out the different options for yourself. Once you have an idea of how it works and what you can do with it, then it\u2019s time to take the next step and try Qodana on your own project.<\/p>\n

Using Qodana on your project<\/h2>\n

Qodana is packed into a ready-to-use Docker image. You can run it:<\/p>\n