Accomplish More With a Custom Code Inspector and 7 Other Qodana Release Features

Kerry Beetge

Read this post in other languages:

• 한국어
,
• 简体中文

JetBrains Qodana has been the talk of the code quality town since its official commercial release in July 2023.

Not only is it the official JetBrains static code analysis platform for teams and therefore highly compatible with JetBrains IDEs and team tools, but Qodana also comprises a range of unique inspections (and a custome code inspector), accompanied by outstanding customer support throughout your experience.

Qodana’s global adoption marks the perfect time to unveil new functionalities and updates, bolstering teams to uphold software quality in an industry that needs it more than ever.

Whether you’re looking to create custom inspections for your team, enable PRs/MRs analysis for your .NET project to become or remain compliant, or simply navigate code analysis results more easily, Qodana is bringing you these capabilities, and more, in the 2024.1 release.

Try Qodana

Jump to:

FlexInspect
Diff analysis for qodana-dotnet
License Audit enabled, out-of-the-box
GitLab Code Quality and BitBucket Code Insight support
IDE Plugin UX improvements
Default linter choice when it’s not defined via qodana.yaml
Custom name for qodana.yaml configuration file
Book a demo

FlexInspect – custom code inspector

Every team has unique needs when it comes to code quality. As it stands, no single code quality tool covers the full spectrum of rules by default, potentially leaving gaps for teams with specific requirements.

With Qodana’s FlexInspect (a custom code inspector), you can now create custom code inspections for any rule you want to enforce in your code or repository. Then you can run these inspections against your project in IntelliJ IDEA or using Qodana in your CI/CD pipeline.

This way, you can identify the issues that are specific to your codebase and your team, saving time and effort.

To write a custom inspection using the Kotlin IntelliJ API within IntelliJ IDEA, follow these steps:

• Access the source code’s AST (abstract syntax tree).
• Debug how a new inspection functions on the code in real time.
• Observe your new custom inspections in action, including the highlighting of code segments that do not meet the expected behavior.
  

With this feature, you get access to PSI – the API used by all IntelliJ and Qodana inspections, and can implement any additional custom checks that you might need.

Here’s how you can access the AST of your code with the IntelliJ IDEA PSI viewer:

FlexInspect allows you to analyze code in a variety of languages, including Java, Kotlin, JavaScript, TypeScript, PHP, Go, Python, Ruby, SQL, XML, CSS, YAML, JSON, shell, and Dockerfile. We’re working on expanding this list, so stay tuned!

Please note: Implementing custom inspections requires you to write code in Kotlin, which means you will need to use IntelliJ IDEA Ultimate.

Also, as this is the first release of FlexInspect, our support team is on standby to assist you should you encounter any issues. Contact us for help at qodana-support@jetbrains.com, or submit any bug reports to the Qodana issue tracker.

Diff analysis added to Qodana for .NET

Now you can use the QDnet linter to only analyze merge and pull requests when you’d like to, rather than having it scan your entire codebase.

Use this mode to run incremental or diff analysis on a change-set, i.e. on a merge or pull request. For users of qodana-github-action, this change will be picked up automatically.

How to use it:

“I just finished my commit and want to analyze my changes.”

qodana scan --diff-start=$GIT_START_HASH

“I want to analyze a set of changes between two commits.”

qodana scan --diff-start=$GIT_HASH_START --diff-end=$GIT_HASH_END

“I am using the Qodana GitHub action for my CI runs.”

It will work automatically.

Please note: This feature is only supported by the paid Qodana for .NET linter but not by the Qodana for .NET Community linter.

License Audit enabled by default

Compliance can be a nightmare without the right tools, which is part of why our License Audit feature is so popular with users. Now the License Audit feature is enabled by default (if you have the Ultimate Plus license, the only license that supports this feature in general).

Any information that Qodana finds about your project dependency licenses will be automatically displayed in the License Audit tab of your project in Qodana Cloud, so you don’t need to configure your analysis to run it.

We’ve also made it possible for existing License Audit users to view audit issues in the Qodana Cloud UI tab, instead of in the overall problems list. If you and your team would prefer to keep seeing license issues in overall problems, please update your configuration accordingly.

GitLab code quality and BitBucket code insight support (pull request decoration)

Starting with 2024.1, Qodana linters support pull request decoration for BitBucket Pipelines and GitLab CI. Previously, this functionality was only available for GitHub Actions.

Now Qodana is able to enhance code reviews with automated insights into code quality directly within the pull or merge request interface for GitHub Actions, GitLab CI, and BitBucket Pipelines.

Thanks to this integration, you can access the specific lines of code where issues were detected, along with descriptions of the problems and possible solutions or recommendations – right from your pull or merge request.

How to enable the feature:

• BitBucket Code Insights: No additional configuration is needed – just update your linter to the 2024.1 version.
• GitLab Code Quality: Additional configuration is needed (specify the report file location).

    script:

 - qodana --results-dir=$CI_PROJECT_DIR/.qodana/results
            --cache-dir=$CI_PROJECT_DIR/.qodana/cache

  artifacts:

        reports:

     codequality: .qodana/results/gl-code-quality-report.json

Default linter choice when not defined via qodana.yaml

We’re introducing a change in the default linter choice for JVM and Python projects. To provide users with the most advanced and feature-rich analysis capabilities, Qodana will now default to using the Ultimate versions of our linters – QDJVM for JVM projects and QDPY for Python projects – over the Community versions (QDJVMC and QDPYC, respectively).

This change means that, if your qodana.yaml configuration does not specify a particular linter version and the Qodana Cloud token is not provided, the Ultimate version will be used automatically.

Should you prefer the Community version, make sure to explicitly define this in the qodana.yaml file to avoid disruptions after your upgrade to Qodana 2024.1.

Improved UX for the IDE plugin

1. Qodana highlighting no longer duplicates the IDE’s highlighting. If a problem from the Qodana report is already highlighted by the IDE, the Qodana plugin doesn’t try to highlight it.
2. When you fix one of the problems listed in the Qodana report or adjust the related piece of code, the Qodana plugin automatically updates the status of the problem in the report to Fixed (if it was fixed) or Not found (if the related piece of code was removed).
   
   This way, you can immediately see which problems from the report have been addressed, and continue working on the rest.
   

Configuring quality gates by problem severity

You don’t want to fail your builds because of low severity issues. Now you can fine-tune the build failure.

Now, all linters, except for Qodana Community for .NET, support configuring individual quality gates for each problem severity. If any of these settings are exceeded — including the total number of problems — the build will fail.

failureConditions:
  severityThresholds:
    any: <number> # Total problems
    critical: <number> # Critical and other severities
    high: <number>
    moderate: <number>
    low: <number>
    info: <number>

Parameter for custom qodana.yaml file

Version 2024.1 simplifies the process of running multiple Qodana builds with various configurations on the same repository. Previously, Qodana linters relied on a fixed qodana.yaml file name for configuration. Changing configurations for different CI jobs required replacing the file.

Also, if you had a monorepository with, for example, JavaScript, PHP, and Python, and you ran three respective jobs, you might have wanted to use different qodana.yaml files, but in the past you couldn’t do this.

Starting with Qodana 2024.1, you can use any file name and just pass it as a parameter. All linters now provide an optional parameter called config that allows you to pass any file as a configuration.

Usage examples:

#qodana-cli
qodana scan <code>config</code> custom.qodana.yaml

#qodana docker
docker run \\
  -v <source-directory>:/data/project \\
  -v <output-directory>:/data/results \\
  jetbrains/qodana-jvm:2024.1 \\
  --config .qodana/license-check.qodana.yaml

These are some of the most important highlights for now but there are more on the way soon. If you’d like to see a new feature or functionality that you feel is missing, please let us know on the Qodana YouTrack board. You can read the full Qodana 2024.1 release documentation for more. Or get in touch with us for a demo of our custom code inspector.

Get the news first

Follow Qodana on Twitter and LinkedIn or read our blog to be the first to hear what’s new with the productor catch special events in your area or online.

Schedule a Qodana demo

Subscribe to Qodana Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!