Create Custom Code Inspections in IntelliJ IDEA – and More – With Qodana 2024.1
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, 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.
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 – a new way to write custom inspections
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, 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
- 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.
- 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.
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.
Subscribe to Qodana Blog updates
