Forem: JetBrains Qodana

Qodana Is Out Of Preview With First-Class JetBrains IDE Integration

Valerie Kuzmina — Fri, 21 Jul 2023 08:33:58 +0000

JetBrains has always strived to deliver tools that make developers’ work enjoyable, creative, and thought-provoking. JetBrains IDEs are designed to understand code and provide valuable suggestions for improving it. Having these tips available in the editor is incredibly helpful. But modern CI-centric workflows require a reliable quality gate in your build pipeline. With that in mind, we created Qodana.

Qodana is the only code quality platform on the market that uses inspections native to JetBrains IDEs and expands the smartness of your JetBrains IDE to the CI server.

We built this powerful static analysis engine to enable development teams to automate code reviews, build quality gates, and enforce code quality guidelines enterprise-wide – all within their JetBrains ecosystem. The platform can be integrated into any CI/CD pipeline and can analyze code written in 60+ languages, including Java, JavaScript, TypeScript, PHP, Kotlin, Python, Go, and C#.

Today, Qodana announces a huge milestone: It’s no longer in preview and is available commercially with some major improvements. Get in now to enjoy a 50% discount on your first year.

Try Qodana for free

What’s new in Qodana 2023.2

Many of you have been wondering where the name “Qodana” came from. Let us explain.

“Qodana” stands for “code analyzer”.

Back in 2021, after weeks of fruitless brainstorming on the product’s name, we turned to one of our polyglot colleagues for guidance. Ten minutes later, she suggested “Qodana” and right away we knew that was it.

Since launching Qodana in EAP in 2021, we’ve been overjoyed by the response. To date, Qodana analyzes commits to over 9K unique projects on a monthly basis – 80% of these projects are commercial.

Our early adopters have taught us a lot about what they need, and we’ve used that knowledge to make some major improvements to the static code analysis engine of Qodana.

1. Server-side analysis by Qodana is now fully integrated with JetBrains IDEs 2023.2

Static analysis tools are known to be complicated to configure. With the Qodana 2023.2 release, we’ve eliminated this pain by fully integrating our code quality platform with almost all JetBrains IDEs: IntelliJ IDEA, WebStorm, PhpStorm, PyCharm, Rider, and GoLand. Please note that this functionality won’t be available until the release of the 2023.2 versions of our IDEs.

This integration will bring two important benefits.

The first benefit is the ease of configuration. You can try the local analysis with just a few clicks, view the list of problems across your entire project, and then configure Qodana in your preferred CI/CD system to establish the quality gate and run server-side checks.

The second benefit is an improved code quality workflow. Once Qodana is configured in the continuous integration server, you’ll be able to see the results of the server-side analysis without leaving the IDE – right out of the box. Alternatively, you can navigate directly to Qodana Cloud to see the issue overview in a straightforward sunburst diagram.

2. Code coverage support

Qodana now supports processing code coverage for Java, Kotlin, PHP, JavaScript and TypeScript. While running automated tests, Qodana will display how much of the code has been executed by relying on the output from the known unit testing frameworks. This way, users will be able to 1) review the degree of code coverage, 2) spot parts of the code that need more testing, 3) assess the quality of the tests themselves.

3. Vulnerability checker based on the Checkmarx data

Now Qodana is bundled with the vulnerability checker, powered by IntelliJ IDEA. This inspection is designed to spot vulnerable external packages used in the project. The data about vulnerabilities is provided by the software security company Checkmarx.

The vulnerability checker goes beyond just providing security information. It also offers valuable remediation insights. Developers can take immediate action to address vulnerabilities by quickly migrating to a safe and stable version of the package without known vulnerability issues.

4. Quick-fixes (experimental)

All Qodana linters (except for .NET) will provide users with the power of quick-fixes to boost their coding efficiency. Qodana is now able to apply quick-fixes to issues that can be resolved automatically and create a new pull request with the applied changes (currently available only for GitHub Actions). Then, the user will be able to review these changes before committing.

For the complete list of changes, refer to What’s new in Qodana 2023.2.

Qodana features beyond the 2023.2 release

In case you haven’t tried Qodana yet, here’s a brief overview of features that are currently available in the product – beyond the newly released ones.

2500+ code inspections – exclusive Qodana inspections included

Qodana can spot performance issues, unused declarations, vulnerable dependencies, potential security issues, confusing code constructs, naming and style conventions, and much more.

Interactive inspection reports and dashboards

Discover issues and trends in your code and better understand the quality of your project with our fancy sunburst diagram.

Cloud-based overview of reports

You can accumulate all of your Qodana reports in a single place – Qodana Cloud – and explore project trends with interactive dashboards.

The baseline for getting your technical debt under control

A snapshot of the codebase, or baseline, is taken during specific Qodana runs. You can compare your current code with its baseline state and see new, unchanged, and resolved problems.

For example, you can use the baseline to put less critical issues on the back burner and focus on fixing bugs that are either new or highly critical.

Third-party license audit

Scan dependencies in your code repository to find their licenses and see if they’re compatible with your project license.

Inspection constructor

Looking to scan for a specific problem that Qodana doesn’t cover yet? You can integrate it with third-party inspection tools or create your own plugins.

A video is worth a thousand words, so please feel free to check out the Qodana overview video by our Developer Advocate.

Qodana pricing that makes managers say “Wow”

What decision-makers especially like about Qodana is that we charge per active contributor, regardless of the number of lines in the project. This makes Qodana an especially cost-efficient offer.

Qodana is available in three plans, including a free plan with limited language support, and paid plans starting from $6 per active contributor per month. Paid plans require minimum of 3 active contributors.

The most advanced Qodana plan, which offers more security inspections and the license audit, comes with a one-year 50% discount!

How to get started with Qodana?

Simply head to our website and claim your free trial! You’ll be asked to create an account in Qodana Cloud and connect the specified linter to your project and preferred CI/CD system. It’s that easy!

Our mission is to help developers deliver code they can be proud of. We hope you enjoy Qodana and all the intelligence it packs into a straightforward sunburst diagram. If you have any questions, feel free to submit a ticket to the issue tracker or leave a comment below.

Secure Your PHP Code With Taint Analysis by Qodana

Valerie Kuzmina — Fri, 10 Mar 2023 14:16:23 +0000

It only takes one user to exploit a vulnerability in your project and breach your system. To defend programs against malicious inputs from external users (known as “taints”), development teams add taint checking to their static analysis routines.

In this year’s first release, the Qodana team has delivered taint analysis for PHP in the EAP. The feature is available only in Qodana for PHP 2023.1 (jetbrains/qodana-php:2023.1-eap). Qodana for PHP was the first linter we released, so we decided to let PHP developers be the first to test our new security functionality, too. We plan on adding more languages in the future, after we’ve collected enough feedback.

Read on to learn more about what taint analysis is and how it works in Qodana.

GET STARTED WITH QODANA

What is taint analysis?

A taint is any value that can pose a security risk when modified by an external user. If you have a taint in your code and unverified external data can be distributed across your program, hackers can execute these code fragments to cause SQL injection, arithmetic overflow, cross-site scripting, path traversal, and more. Usually they exploit these vulnerabilities to destroy the system, hijack credentials and other data, and change the system’s behavior.

Example of a taint. Arbitrary data from the GET parameter is displayed on the screen. For example, malicious users can exploit this vulnerability to tamper with your program’s layout.

As an extra layer of defense against malicious inputs, development teams execute taint analysis when they run a security audit on the program’s attack surface.

Taint analysis is the process of assessing the flow of untrusted user input throughout the body of a function or method. Its core goal is to determine if unanticipated input can affect program execution in malicious ways.

Taint sources are locations where a program gets access to potentially tainted data. Key points in a program that are susceptible to allowing tainted input are called taint sinks. This data can be propagated to the sinks via function calls or assignments.

If you run taint analysis manually, you should spot all of the places where you accept data from external users and follow each piece of data through the system – the tainted data can be used in dozens of nodes. Then, to prevent taint propagation, you should take one of the two approaches described below:

Sanitize the data, i.e. transform data to a safe state. In the example below, we removed tags to resolve the taint.

Validate the data, i.e. check that the added data conforms to a required pattern. In the example below, we enable validation for the $email variable.

In other words, the taint analysis inspection traces user-tainted data from its source to your sinks, and raises the alarm when you work with that data without sanitizing or validating it.

How taint analysis works in Qodana

Taint analysis is performed by Qodana for PHP starting from version 2023.1 EAP. This functionality includes an inspection that scans the code and highlights the taint and potential vulnerability, the ability to open the problem in PhpStorm to address it on the spot, and a dataflow graph visualizing the taint flow.

Example #1. SQL injection

Let’s take a look at an example of SQL injection and how Qodana detects it:

Here, Qodana shows us the following taints in the system_admin() function:

Markers 1-2: Data from user form input is retrieved from the $_POST global array with no sanitization or validation and is assigned to the variable $edit. This is a taint.

Marker 3: The tainted variable $edit is passed to the system_save_settings function as an argument without any proper sanitization.

Marker 4: Data from the $edit variable is now located in the $edit parameter.

Marker 5: The $edit variable is passed to foreach with the $filename key and $status value. Both variables contain the tainted data from the $edit variable concatenated with the string. The $filename key is concatenated with a tainted SQL string, and then it will propagate tainted data into an argument passed to the db_query.

Marker 6: The $ filename key contains the tainted data from the $edit variable concatenated with the string.

Marker 7: The $ filename key is concatenated with a tainted SQL string.

Marker 8: Tainted SQL string will propagate tainted data into an argument passed to the db_query

Let’s now look at the db_query:

Marker 9: The tainted string will be located in the $query parameter.

Marker 10: This parameter is going to be an argument of the _db_query function.

Let’s move on to the _db_query function:

Marker 11: Tainted data located in the first parameter $ query of the _db_query function.

Marker 12: Data of the parameter is passed to the mysql_query function, which is a sink.

The whole data flow above illustrates how data moves from $_POST[“edit”] to the mysql_query($query) without any sanitization or validation. This allows the attacker to manipulate the SQL query which was concatenated with a key of $_POST[“edit”] and trigger SQL injection.

Qodana will spot these risks in your codebase along with all nodes where tainted data is used, so you can sanitize all tainted data in a timely manner.

Example #2. XSS problem

In the Qodana UI, you can see a graph that visualizes the entire taint flow. Here’s how Qodana will visualize the XSS vulnerability, which contains 2 sources that would be merged on marker 5.

Source 1

Markers 1-2: Data from the searchUpdate.pos file will be read and tainted data will be assigned to the $start variable.

Source 2

Markers 3-4: Data from files whose path is located in $posFile will be read and tainted data will be assigned to the $start variable.

Marker 5: A merged tainted state from all conditional branches in the $start variable will be passed as an argument to the doUpdateSearchIndex method.

Let’s look inside the doUpdateSearchIndex() method:

Markers 6-8: The $ start parameter will contain tainted data on this dataflow slice and then it will be passed within a concatenated string as an argument to the output method.

Let’s look inside the output method:

Marker 9: Tainted data contained inside the transmitted string will be located in the $out parameter.

Marker 10: Data from the $out parameter will be transferred to the print function without any sanitization. This function is a sink and causes XSS vulnerability, which can be exploited.

To exploit the vulnerability, an attacker can, for example, upload a shell script instead of the expected files in markers 1 and 2, and will be able to put any information onto the web page as a result of an unsanitized print function.

Qodana will alert you to this vulnerability and give it a high priority so that you can resolve it as soon as possible and prevent the hack.

Conclusion

Taint analysis helps eliminate exploitable attack surfaces, so it’s an effective method to reduce risk to your software. To learn about taint analysis and Qodana in detail, explore Qodana documentation.

Happy developing and keep your code healthy!

GET STARTED WITH QODANA

Qodana and IntelliJ IDEA: How a Code Quality Platform Streamlined the Localization of an IDE

Valerie Kuzmina — Mon, 23 Jan 2023 10:33:23 +0000

Have you ever wondered how to make sure that your determination to live a healthier life, not sweat the small stuff, and work smarter, not harder continues past Valentine’s Day? Psychologists say that breaking big goals into small steps is the best way to stick to your New Year’s resolutions.

This advice applies to programmers’ resolutions too. If you plan a large project that involves code refactoring, you may want to see the full picture of the required changes and plan accordingly. This is exactly what the IntelliJ team did when they needed to localize the IDE’s entire UI into Chinese, Japanese, and Korean.

Using Qodana, the code quality platform from JetBrains, as a single source of truth for their localization process, the IntelliJ team managed to finish the project much faster than expected. This positive outcome was a result of wise planning, accountability, and oversight. Here’s how they did it.

TRY QODANA FOR FREE

The challenge: isolate 13,000 hard-coded strings and monitor progress effectively

To streamline the localization of their UI into 3 different languages, the IntelliJ team needed to strip out all localizable items from the source code and put them into separate properties files to be handed over for translation.

With over 13,000 strings, it was easy for some localizable ones to be overlooked, meaning that they remained in the code. When localizing the UI, hard-coded strings can be the most difficult parts to deal with. They are hard to find because they do not show up until the software has been localized. As a result, if a user installed the Japanese language pack, for example, some parts of the UI would still be in English.

The team was therefore left with much tedious and repetitive work. As a result the head of the localization project was looking for a solution that would allow them to:

Automate a huge chunk of the work by continuously inspecting the code base for hard-coded string literals.
Assign issues to the developers who would be responsible for fixing them.
Oversee the extraction of localizable strings.

The solution: automated code inspection for hard-coded string literals

The localization project lead chose Qodana to streamline the code inspection process, resulting in a project with the following steps:

#1. Connect Qodana to TeamCity

The IntelliJ team connected Qodana to their TeamCity pipeline and enabled the Internationalization code inspection to highlight hard-coded string literals that were not extracted into properties files as required.

#2. Configure the inspection profile

In the inspection profile, the team configured the scope of the inspection to make sure that the platform skipped parts like legacy code, literals without alphabetic characters, and strings consisting of only whitespace.

The team also made sure that TeamCity would produce a test report for each line inspected by Qodana and fail it if the string wasn’t extracted.

#3. Decide on the frequency of scans

Once fully configured, Qodana was set to inspect the code every 4 hours. It was especially important that the scan was running independently on the server, as opposed to on someone’s local machine. This ultimately saved the team valuable time.

The first Qodana run resulted in 10,000 failed tests in TeamCity.

Overview of the failed tests.

Qodana flags the hard-coded string literal remaining in the code as an error in the internationalized environment.

#4. Assign tasks

For each of the test failures, the project lead assigned a developer to investigate and extract the hard-coded string to the properties file.

How the assigned test is displayed in TeamCity.

#5. Monitor the results

After each Qodana inspection, TeamCity compared the previous results to the current report. If the developer responsible for an issue extracted the string, TeamCity marked the test as fixed. This allowed the project lead to monitor the progress without having to manually mark tests as fixed.

Additionally, the team was able to monitor progress in the Qodana Cloud dashboard, which updated information on the remaining code issues in real time and compared results between different Qodana runs.

_The Qodana Cloud dashboard example. _

Qodana also allowed adding selected issues to the baseline, otherwise known as the technical debt section. This way, the entire team could see the same list of issues and monitor progress right in the platform. Below is an example of how this works.

The Qodana baseline feature.

The key outcomes

In only a few months, the number of failed tests dropped from 10,000 to zero , an average of about 175 fixed tests per day. The team successfully removed all hard-coded string literals from the source code and the whole UI was localized seamlessly, with no unexpected elements in English.

With Qodana, the IntelliJ team required fewer manual steps in the localization process, thereby reducing the number of human errors and increasing confidence in the localized builds. Additionally, with checks running every 4 hours, they were able to detect issues sooner and prevent small problems from turning into big ones later on.

Finally, Qodana became the single source of truth for the team lead, making it easy to ensure that developers fixed the problems they were assigned.

Thanks to these results, the IntelliJ team will keep using Qodana as a code quality and resource planning platform when they deliver new functionalities or improve IntelliJ IDEA’s performance. More on that in our upcoming posts.

GET STARTED WITH QODANA

Happy developing and keep your code clean!

Announcing the Preview for Qodana Cloud, a One-Stop-Shop for All Your Code Quality Insights!

Viktor Tiulpin — Thu, 08 Dec 2022 13:20:36 +0000

A public preview is now open for Qodana Cloud – a centralized cloud-based solution that collects and displays data from different Qodana linters under one roof. You can use Qodana Cloud to manage your code quality checks in a variety of contexts, ranging from one-person projects to large development teams.

Qodana Cloud is still in development, and to iron out some wrinkles we are calling for the support of the community. If you want to become an early adopter of our new features, read on to learn how to get started with Qodana Cloud.

TRY QODANA CLOUD

How Qodana Cloud can complement your projects

Do you want to run static analysis in multiple projects or repositories? Is your codebase distributed across several servers and virtual private networks? Do your teams work independently, and are they not always on the same page when it comes to code quality? In any of these scenarios, if you wanted to ensure that your code is clean and secure, you previously would need to switch between different linters or Qodana instances to see the results for different projects.

The need to switch between linters can make the code review process convoluted and inefficient, and we’ve developed Qodana Cloud to address precisely this problem. Qodana Cloud collects all the data from different Qodana linters in a single place and allows you to drill down into particular issues with interactive dashboards.

Here is how you can benefit from Qodana Cloud:

Get deeper insights into your projects’ trends

With the ability to aggregate reports from different sources in one view, you can discover trends and patterns in your code across all projects and get a better understanding of how your project or the whole team is performing. This way, developers will no longer code in silos, instead seeing the same list of issues. This also makes it easier for managers to track progress for the whole organization.

You can create separate organizations, teams, and projects in Qodana Cloud and assign a single team to several projects for convenient navigation. In addition, you achieve more transparency thanks to widgets updating in real time.

In each project, you can also see a history of previous results and compare the results of quality checks between commits. You can examine the absolute number of problems detected or compare the number of problems against a baseline – a snapshot of the codebase problems taken during a specific Qodana run.

Open problems detected by Qodana in your favorite IDE

If you are already a Qodana user, you might know that you can open issues spotted by Qodana right in your IDE. And now this feature works for Qodana Cloud, too! This means you can fix server-side errors in the editor the same way you work with other suggestions given by the IDE.

Here’s how it works:

What’s especially important about Qodana being bundled with JetBrains IDEs is that you run resource-intensive checks outside of your development environment without hurting your IDE’s performance. In the example above, Qodana spotted a chance that a variable could be null and cause a runtime exception. This is a severe issue, but users tend to switch off such inspections for the sake of saving resources.

In fact, that’s one of the reasons why we at JetBrains created Qodana, to ensure that you no longer have to choose between code quality and IDE performance!

Plan your work better

Split big projects into small steps! Switching to a newer version of a language or framework, or getting rid of a certain utility or pattern, can be a cumbersome task – especially if you are working on a big project involving many developers and QA engineers.

In Qodana Cloud, you can build a report to evaluate all pieces of code requiring modification and select issues to add to the baseline – otherwise known as the technical debt section. This way, the whole team can see the same list of issues and monitor progress with an interactive Qodana dashboard.

Choose the dark or the light side

In the design world, dark mode is the new black. Who are we to ignore that? To ensure you have a good experience with Qodana Cloud, we’ve provided the option to manually choose the dark or the light theme or have the UI sync automatically with your system preferences.

What’s coming next?

In future releases, we will add role-based access control so that you can grant different permissions based on a user’s responsibilities. For example, perhaps your legal team only needs the ability to view reports about licenses used in a product, or your security team needs to see a list of vulnerabilities in the codebase. You will be able to create custom roles for them with permissions that are specific to their tasks. We are also working on implementing more security controls and allowing quick-fixes for certain types of issues.

A sneak peek of what’s coming next in Qodana Cloud.

How to get started with Qodana Cloud

To get started, go to qodana.cloud and log in with your JetBrains Account. Alternatively, as a non-registered user, you can explore demo projects that were already analyzed by Qodana Cloud to see it in action.

To pull your inspection reports from other Qodana instances into the cloud, Qodana Cloud will generate a token for you to set into your project in your CI tool. For detailed instructions, see our documentation.

Project setup

Setting up a project in Qodana Cloud takes five simple steps:

Trigger the first run. First, Qodana analyzes your project using vital checks only. It will identify the number of files and folders containing problems, the languages used, and other important info about your project.
Customize your analysis. Next, Qodana offers you the option to enable extra inspections that might be critical for your analysis.
Narrow the analysis down. You can then exclude certain files and folders from the analysis.
Create technical debt. Our favorite part is the ability to add detected problems to the baseline, allowing you to get back to them when you have time.
Apply the inspections throughout the project. To apply the selected settings to your project, download qodana.yaml and qodana.sarif.json, put them in the root folder, and restart Qodana.

That’s all for now! If you have any suggestions for future blog topics or if you want to learn more about how Qodana can help you and your business, post a comment here, tag us on Twitter, or contact us at qodana-support@jetbrains.com.

Happy developing, and keep your code clean!

Qodana 2022.3 EAP Is Out: Qodana for .NET and Go and 100+ New Inspections

Viktor Tiulpin — Wed, 02 Nov 2022 11:22:28 +0000

We’re delighted to announce the release of Qodana 2022.3 EAP. This version of the platform brings support for NET. and Go, and over 100 new inspections for cleaner code. However, please, note that Qodana 2022.2 images are more stable, as Qodana 2022.3 EAP is still in its infancy.

Read on to learn more and become an early adopter of some exciting new features!

GET STARTED WITH QODANA

Our brand new linters bring all of the smarts from Rider and GoLand to enable you to spot anomalous code and potential bugs, eliminate dead code, improve the overall code structure, and introduce coding best practices across all of your .NET and Go projects!

Qodana for .NET

Qodana supports almost all .NET inspections provided by Rider. Since there’s a long list of them, check out the Rider documentation to learn more about all of the inspections. Meanwhile, a few examples of the .NET inspections that Qodana can run are below.

Inconsistent lock ordering

One of the main issues when using locks to achieve thread safety is avoiding deadlocks, i.e. when threads simultaneously block each other from continuing execution, so no progress is made. With this new inspection, Qodana will highlight cycles leading to possible deadlocks at runtime.

Access to modified captured variable

Qodana for .NET detects access to the captured variable from an anonymous method when the variable is modified externally.

Avoid using ‘async’ lambda when delegate type returns ‘void’

This inspection spots the usage of ‘async’ lambda expressions: any exceptions unhandled by the lambda will never affect the caller thread and will not be caught with the catch clause.

Type check and casts can be merged

The type-testing is operator in its classical form (Expression is Type) returns true only when the runtime type of Expression is compatible with Type and the result of Expression is not null.

When we use is to check the compatibility before casting, like in the example below, we encounter at least two problems:

We perform the type check twice for no reason, which can affect performance if we do it inside a loop.
The fact that the program execution will not get into the if statement if obj is null is not immediately clear to those who read this code.

Qodana will spot this issue and suggest you fix it right in Rider.

Lambda expression/anonymous method should not have captures of the containing context

The lambda expression/anonymous method passed to a parameter annotated by the ‘[RequireStaticDelegate]’ attribute must not have captures of the containing context (local variables, local functions, ‘this’ reference) to avoid heap allocations.

To configure the linter for .NET and run analysis, please refer to the Qodana documentation.

Qodana for Go

Qodana 2022.3 is designed to support all inspections provided by GoLand. To see the exhaustive list, please refer to the GoLand documentation. Below are examples of some of the Go inspections that Qodana now supports.

Placeholder argument ‘d.DeletedCount’ has the wrong type ‘int64’ (%s)

This inspection reports incorrect usages of fmt.Printf, fmt.Println, and similar formatting and printing functions.

In their format strings, formatting functions use formatting verbs, like %s, %d, %v, and others.

If formatting verbs are used incorrectly, the result of a formatting function will contain an error.

Unhandled error

This inspection reports calls to functions and methods that do not handle the call result of the error type.

An API of such functions imply that their execution might finish unsuccessfully and they would return an error. Calls that do not handle the error result could be an indication of misuse of the API.

Unused dependency

This inspection reports unused dependencies on your project. It’s good practice to scan for unused dependencies on a regular basis, as it reduces the library size of your project and improves maintainability.

To see Qodana in action and play around with these new inspections, feel free to jump into our documentation and see how to configure linters for Go.

New inspections

Besides adding new linters for .NET and Go, Qodana 2022.3 also brings you over 100 new inspections for the existing linters. Let’s take a look at the most prominent examples of inspections for Java, Kotlin, and Python.

Java and Kotlin inspections

We’ve added over 40 new inspections to Qodana for JVM Community and Qodana for JVM.

DataFlowIssue

This inspection reports code constructs that always violate nullability contracts, may throw exceptions, or are redundant, based on data flow analysis.

EscapedSpace

Java 15 introduced the string escape sequence \s to make trailing whitespace in text-blocks visible. In most other contexts, especially in regular expressions, this escape sequence can easily be confused with the \s of a regular expression meaning whitespace. In Java string literals it has to be written as "\\s" instead.

MismatchedJavadocCode

This inspection reports cases in which the Javadoc of a method obviously contradicts the method signature, such as the comment saying “returns true” when the method returns a string.

Destructure

This inspection reports declarations in Kotlin that can be destructured.

UnresolvedRestParam

Now Qodana can detect inconsistent method declarations in REST services (such as @PathParam parameters that don’t match a placeholder from the @Getannotation), as these would throw exceptions at runtime.

ReactiveStreamsThrowInOperator

This new inspection spots throw statements in Reactor/RxJava operator code instead of returning designated error values, which prevents the errors from being processed further. For example, it ignores them or replaces them with a fallback value.

Please, note that this version of Qodana also brings all of the new inspections for Android from IntelliJ IDEA 2022.3 and Android Studio – Electric Eel | 2022.1.1.

Python inspections

We’ve also added some inspections for the Google App Engine to Qodana for Python that will highlight issues before they cause failures in production environments. For example, now you can spot:

GQL queries that do not comply with restrictions for queries allowed on the Google App Engine server.
GQL queries without indexes.
Usages of Python features that are restricted by the Google App Engine sandbox.
Сases when threadsafe is not enabled with the CGI handler.

To exclude certain inspections from your analysis, you can customize your default inspection profile or create a brand new one. You may also want to enforce inspections that are important to your coding guidelines. Check out our Qodana documentation for more information.

That’s everything about Qodana 2022.3 EAP! We hope you enjoy this new release. If you have any suggestions for future blog topics or if you want to learn more about how Qodana can help you and your business, post a comment here, tag us on Twitter, or contact us at qodana-support@jetbrains.com.

Happy developing and keep your code clean!

Your Qodana team

Qodana 2022.2 Is Available: 50+ New Inspections and CircleCI Orb

Viktor Tiulpin — Fri, 05 Aug 2022 15:12:57 +0000

Qodana 2022.2 is now available, bringing new and improved code inspections for Java, Kotlin, Android, PHP, JS, and Python. Additionally, we’ve added CircleCI Orb to the Qodana integration toolset.

GET STARTED WITH QODANA

More CIs to run Qodana with

Qodana already has plugins for Azure Pipelines, GitHub Actions, and TeamCity. Starting from 2022.2, we’ve prepared a CircleCI Qodana orb that allows you to set up code inspections quickly and easily with your CircleCI projects.

Also, it’s easy to set up Qodana in GitLab, Jenkins, or any other CI that supports running Docker images.

New inspections

Regular expressions

Regular expressions are widely known for their complexity, intricate syntax, and sometimes verbosity. To make life easier, we’ve added new inspections in this area. Previously these inspections were available only for Java, but we’ve now made them available for all languages.

Simplified regular expressions

A regular expression like [\wa-z\d] can be simplified to just \w since \w already includes a-z as well as the digits. It helps improve the code’s overall readability.

Suspicious backreferences

A regular expression like \1(abc) cannot match anything. This is because the \1 refers to the abc that is not yet defined when evaluating the \1. This inspection prevents simple typos in regular expressions and speeds up the editing experience.

Redundant `\d`, `[:digit:]`, or `\D` class elements

The regular expression [\w+\d] can be written as [\w+], as the \w already includes the \d. It helps improve the code’s overall readability.

Markdown support

Incorrectly numbered list items

Ordered list items like 1. 2. 4. are marked as being inconsistently numbered. In the rendered Markdown, the list is still displayed as 1. 2. 3., but the inconsistency makes editing the source code harder.

Java, Kotlin, and Android inspections

We’ve added and reorganized inspections in the categories: Javadoc, DevKit, Markdown, Kotlin language, style, architectural patterns, performance, and JUnit support. Here are a couple of examples from the JUnit set.

JUnit: Malformed Declaration

Reports the JUnit test member declarations that are malformed and are likely not to be recognized by the JUnit test framework. Declarations like these could result in unexecuted tests or lifecycle methods.

JUnit: Unconstructable TestCase

Reports JUnit test cases that can’t be constructed because they have an invalid constructor. Test cases like these will not be picked up by the JUnit test runner and will therefore not execute.

Those examples you can see live on our public TeamCity instance. Please use the Guest login to enter. Other inspections are described in our documentation.

PHP inspections

We added inspections in Probable bugs, Documentation, Style, Testing, and Laravel categories, for example:

Probable bug: Number ranges mismatch

In a function that is declared with returns int<0,10>, marks return statements that return a number outside this range. Similarly for fields, field constructors and function calls.

Documentation: Type tag without variable name

The PHPDoc snippet @param string is redundant as it doesn’t say what is a string. It should be either removed or replaced with @param string $argument, saying that argument is a string.

Blade: Parse error due to unpaired parentheses in string literals

Early detection of unpaired parentheses in string literals that are later parsed by Blade, a template engine.

To include or exclude certain inspections from your analysis, you can customize your default inspection profile or create a brand new one. You may also want to enforce inspections that are important to your coding guidelines or best practices. Check out our Qodana documentation for more information.

If you have any suggestions for future blog topics or if you want to learn more about how Qodana can help you and your business, post a comment here, tag us on Twitter, or contact us at qodana-support@jetbrains.com.

Your Qodana team

Qodana 2022.1 Is Available

Anastasia — Thu, 12 May 2022 13:06:40 +0000

We are continuously adding new functionality and improving Qodana, our code quality platform. To keep you updated about what’s new, we’re starting a series of regular release blog posts with the major release of Qodana 2022.1.

License audit has been an extra linter that had to be configured separately from the main linters. It now comes with Qodana out of the box. We also added a bunch of new and useful inspections for PHP and JVM linters. Read on to learn more!

GET STARTED WITH QODANA

License audit

Legal and compliance penalties for invalid or inappropriately used licenses in your code can be extremely costly. With Qodana, you can scan dependencies in your code repository to find their licenses and see whether there are any potential issues.

With this release, we’ve made it easy to bring license auditing into your project and make it a part of your CI/CD pipeline. The new License audit feature is available for all linters, including Python, Java, Kotlin, PHP, and JavaScript.

To enable License audit, add the following lines to the qodana.yaml file in your project root:

include:
  - name: CheckDependencyLicenses

If you need to ignore a specific dependency in your project, add the following lines:

dependencyIgnores:
- name: "dependency/name"

Read our documentation for more information about custom configurations for License audit and check out this blog post to see how it can streamline working routines for developers, managers, and legal teams.

PHP inspections

This version of Qodana brings all of the new inspections from PhpStorm 2022.1 and adds them to your pipeline with our PHP linters. PhpStorm comes bundled with Qodana, so when Qodana notifies you about an issue in your code, you can open it right in your IDE for further investigation.

Duplicate array key

The behavior of array_merge() and merging with the + operator are different from each other in PHP. The latter will not override the value if the key is duplicated. This can lead to confusion and bugs, so Qodana for PHP now highlights such cases.

Usage of count($array) as array index

When appending an item to an array, there is no need to explicitly specify the index. Qodana for PHP can warn you about the redundant count() call.

Replace pow() call with **

PHP has had an ** exponentiation operator available since version 5.6. Qodana for PHP will suggest a quick-fix right in PhpStorm (Alt+Enter) to replace the old pow() calls with the ** operator.

Read-only properties

Private properties with read-only access inside a class can be declared with the readonly flag. Qodana for PHP will suggest updating the property declaration.

Final class constants

Starting with PHP 8.1, it is possible to declare constants as final. This is why Qodana for PHP will warn you about constants that are not inherited and suggest adding a final modifier to them. With the PhpStorm integration, you can quickly jump to the IDE to fix the issue.

rand function arguments in reverse order

This inspection highlights function calls from the rand family where the max argument can be less than the min. For example, calling rand(10, 1) is the same as calling rand(1, 10), but mt_rand() is strict about the order of its arguments.

Invalid mock target with PHPUnit

Qodana for PHP will warn you when you try to access a private or final method on a mock object.

Redundant modifier

This new inspection will report modifiers that are used in regular expression patterns but do not affect the match:

/i(case insensitivity) in patterns that contain no letters.
/D (PCRE_DOLLAR_ENDONLY) in patterns that do not contain a dollar sign or that contain the \m (PCRE_MULTILINE) modifier.
/s(dot matches line breaks) in patterns that contain no dots.

Unsupported modifier

This inspection will report usages of the /e modifier, which is deprecated in PHP versions 7.0 and later.

Java and Kotlin inspections

This release also adds new inspections from IntelliJ IDEA 2022.1 to Qodana for JVM. With our IntelliJ IDEA integration, if any issues are found, the erroneous code can be opened right in the IDE for a quick fix.

Let’s take a look at the most notable inspections.

Suspicious back reference

Qodana for JVM will find references that will not be resolvable at runtime.This means that the back reference can never match anything. A back reference will not be resolvable when the group is defined after the back reference, or if the group is defined in a different branch of an alternation.

‘InputStream’ and ‘OutputStream’ can be constructed using ‘Files’ methods

This inspection reports FileInputStream and FileOutputStream constructors when they can be replaced with Files.newInputStream() and Files.newOutputStream(), respectively. Streams created using Files methods are usually more efficient than those created by stream constructors.

Redundant @ScheduledForRemoval annotation

Qodana for JVM will warn you about the usage of @ApiStatus.ScheduledForRemoval annotations without the inVersion attribute, which targets Java 9 or a newer version of Java. It will suggest replacing such usages with the forRemoval attribute in the @Deprecated annotation to simplify your code.

Bulk ‘Files.readAttributes’ calls can be used instead of multiple file attribute calls

This inspection finds places where multiple java.io.File attribute checks, such as isDirectory, isFile, lastModified, or length, are used in a row. These calls can be replaced with a bulk Files.readAttributes call. The bulk method is usually more performant than multiple attribute checks.

Loop can be replaced with ‘List.replaceAll()’

This inspection reports loops that can be collapsed into a single List.replaceAll() call.

Number of placeholders does not match the number of arguments in logging call

Qodana for JVM will report SLF4J or Log4j 2 logging calls, such as logger.info(\"{}: {}\", key), where the number of {} placeholders in the logger message doesn’t match the number of other arguments in the logging call.

Regular expressions can be simplified

This inspection detects regular expressions that can be simplified.

To exclude certain inspections from your analysis, you can customize your default inspection profile or create a brand new one. You may also want to enforce inspections that are important to your coding guidelines or best practices. Check out our Qodana documentation for more information.

That’s all that is new in Qodana 2022.1! We hope you’ll find our release blog posts useful. If you have any suggestions for future blog topics or if you want to learn more about how Qodana can help you and your business, post a comment here, tag us on Twitter, or contact us at qodana-support@jetbrains.com.

Your Qodana team

Why Do Testers Need CI/CD?

Alexandra Psheborovskaya — Thu, 14 Apr 2022 09:04:46 +0000

Competency in the TestOps field is now just as much of a basic requirement for QA engineers as the ability to write automated tests. This is because of the ongoing development of CI/CD and the increasing number of QA engineers who work with pipelines (or the sequence of stages in CI/CD) and implement their own. So why is CI/CD such a great tool for quality control? Let’s find out.

Running tests automatically

Automated tests haven’t been run locally in what feels like ages. These days, CI/CD pipelines run tests automatically as one of their main functions.

Pipeline configuration can be assigned to DevOps. But then we will be a long way from making use of CI/CD’s second function: quality control, or more precisely, “quality gates”.

Quality control using quality gates

But what are quality gates? Let’s say the product code is like a castle. Every day, developers write new code – which could weaken the foundations of our castle or even poke holes in it, if we are really unlucky. The purpose of a QA engineer is to test each feature and reduce the likelihood of bugs finding their way into product code. Lack of automation in the QA process could cause QA engineers to lose sleep, since there is nobody to watch over all the various metrics – especially at dangerous times, like Friday evenings when everyone wants to leave work and is hurrying to get everything finished. An ill-fated merge at that moment can cause a lot of problems down the road.

This problem can be solved by building in quality checks.

Each check deals with a different important metric. If the code doesn’t pass a check, the gates close and the feature is not allowed to enter. A feature will only be merged into the product when it passes all the checks and potential bugs have been prevented.

What quality checks can be included in CI/CD?

We need to put together a list of checks to ensure that the process is as automated as possible. They can be sequenced in “fail first” order. A feature needs to pass all the checks to get through the pipeline successfully. The initial checks are the ones that make sure the app is capable of working: build, code style check, and static analysis.

“Build” speaks for itself: if the app cannot be built, the feature does not progress. It is important to incorporate a code style check into your CI/CD pipeline to ensure the code meets unified requirements, as doing so allows you to avoid wasting time on this kind of bug during code reviews.

Static analysis is an extremely important tool for judging code quality. It can point out a huge number of critical errors that lead to bugs.

We then continue with stage-two checks: unit tests with coverage analysis and coverage quality control, as well as integration and systems tests. Next, we review detailed reports of the results to make sure nothing was missed. At this stage we may also perform a range of non-functional tests to check performance, convenience, and security, as well as screenshot tests.

When developing a pipeline, we need to pay attention to two competing requirements:

The pipeline must guarantee the best possible feature quality in light of your needs.
Time spent running the pipeline should not slow down your workflow. It should generally take no more than 20 minutes.

Examples of tools to incorporate in quality checks

Code style highlighting

A code style is a set of rules that should be followed in every line of code in a project, from alignment rules to rules like “never use global variables”.

You might be wondering what style has to do with testers. The answer is a lot, actually. A style check provides several benefits for QA experts, not to mention the rest of the team:

A unified style helps developers work with the code and gives them more time to implement new features and fix bugs.
A unified style allows you to dispense with manual code checks and use a CI/CD tool to run the checks instead.

Large companies usually have their own style guides that can be used as examples. For instance, Airbnb has a JavaScript style guide and Google has a number of guides. You can even write your own.

The choice of tools for code checking depends on the language. You can find a suitable tool on GitHub or find out which tools other teams are using. Linters use bodies of rules and highlight code that fails to abide by them. Some examples include ktlint for Kotlin, checkstyle for Java, eslint for JavaScript.

Static code analysis

Static code analysis is a method of debugging by examining source code without executing a program. There are many different static code analyzers on the market. We’ll take a look now at a platform we’re developing ourselves – Qodana. The major advantage of this code analyzer is that it includes a number of inspections that are available to us in JetBrains development environments when we’re writing code.

Many of you probably use an IDE-driven approach, where the IDE helps you write code and points out various bugs such as suboptimal code usage, NullPointerExceptions, duplicates, and so on.

But unfortunately, you can never be sure all the critical problems found by the IDE were fixed before the commit. One way you can guarantee that all the problems will be addressed is by incorporating Qodana into your CI/CD pipeline. If you can’t fix everything at once, you can select critical problems, add them to the baseline, and gradually work your way through the technical debt. This allows you to avoid slowing down the development process while keeping the problems that have been found under control.

Test coverage

Code coverage is a metric that helps you understand how well your code has been covered by your tests (generally unit tests).

Here you need to define the minimum coverage percentage that you want to support. The code won’t be able to go live until it has been covered sufficiently by the tests. The minimum percentage is established empirically, but you should remember that even 100% coverage may not completely save your code from bugs. According to this article from Atlassian, 80% is a good figure to aim for.

Different coverage analyzers are available for different languages, such as Jacoco for Java, Istanbul for JavaScript, or Coverage.py for Python. You can build all these analyzers into your CI/CD pipeline and track the metrics with ease.

Shaping the release process

In addition to automatically running tests and ensuring particular code quality requirements are satisfied, CI/CD lets testers organize the release process.

The release process can be complex and can depend on a lot of different manual actions. It is often a completely manual process: the artifact is created by a developer, then passed to the testers for checks, and finally comes to the person who knows how to roll it out for the go-live. Once again, there are a lot of potential choke points here. For instance, one of those people could fall ill or go on vacation.

An effective release process will look different for each team, but it will generally include the following steps:

Each change in the Git branch triggers a build of the app.
The build undergoes quality checks and does not become part of the main branch until it passes all the checks successfully.
A release candidate is taken from the release branch or the main branch: this fixes the version and guarantees that nothing will go live unless it has been tested and has not been changed afterwards. This helps with tracking releases and all the changes they include. In addition, by storing artifacts of the stable version, you make it possible to revert to them quickly in the event of an unsuccessful release.
The release candidate is tested and undergoes final checks.
The release candidate goes live. This may be either a manual pipeline launch or an automated launch, if the release candidate passed all the checks at the preceding stage. The choice between an automatic release process and a manual one will depend on how frequent and how important the releases are, as well as the preferences among team members and the convenience of the rollout.

Any CI/CD system allows you to set up this kind of process. The process should be convenient for the whole team, including the testing team.

Given the factors outlined above, we believe following these basic rules will help ensure an easy and efficient release process:

Artifacts must be ready for download and testing, ideally all in one place.
As many checks and tests as possible must be automated. They should take place without human intervention.
All complex operations with builds should be as automated as possible.
All builds that will go live should be recorded and remain available for a certain period after release. This will help if you need to investigate errors in the production version, reproduce bugs, or just track the history.

We would also like to remind you that if quality metrics are not controlled automatically and do not affect anything, they are useless, as there’s no way to guarantee that these metrics will be adhered to.

Implement pipelines, automate processes, and use static code analysis!

Your Qodana team

Introducing Qodana for Azure Pipelines

Anastasia — Thu, 07 Apr 2022 11:26:11 +0000

With Qodana, you can detect, analyze, and resolve code issues right in the CI/CD system you rely on. Since Qodana was released, we’ve supported GitHub Actions, GitHub App, GitLab CI/CD, TeamCity, and Jenkins. We continue to expand our integrated environments to make sure we bring code quality into your favorite CI/CD. This time around, we’re introducing a new extension for Azure Pipelines.

Try for free

Qodana linters are now integrated into your Azure DevOps repositories to allow you to make code analysis a part of your build pipeline and ensure the maintainability and reliability of your projects. You can integrate Qodana with Azure Pipelines in just 2 steps:

Install Qodana for Azure Pipelines
Configure Qodana to analyze your code

Now let’s dive into the details.

Install Qodana for Azure Pipelines

From Visual Studio Marketplace, install the Qodana for Azure Pipelines extension by clicking the Get it free button, and Proceed to organization once the installation has finished.

If you do not have the required permissions to install an extension from the marketplace, a request will be sent to the account administrator to ask them to approve the installation.

Configure Qodana to analyze your code

Set up a pipeline that integrates with Qodana

Before analyzing your code, you will first need to set up a new build pipeline that integrates with Qodana. On the Azure DevOps panel, go to Pipelines and click Create Pipeline. If any pipelines have already been created, select New pipeline.

You can configure the pipeline with either the YAML editor or the classic editor. When using the classic editor, you can take advantage of the predefined templates. The YAML editor requires you to use a YAML file. Let’s choose the latter for this example.

The YAML editor will open with the template YAML file. In order to configure it correctly you will need to configure the Qodana Scan task by editing your azure-pipelines.yml file:

# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml

trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - task: Cache@2 # Not required, but Qodana will open projects with cache faster.
    inputs:
      key: '"$(Build.Repository.Name)" | "$(Build.SourceBranchName)" | "$(Build.SourceVersion)"'
      path: '$(Agent.TempDirectory)/qodana/cache'
      restoreKeys: |
        "$(Build.Repository.Name)" | "$(Build.SourceBranchName)"
        "$(Build.Repository.Name)"
  - task: QodanaScan@1

You can also find the Qodana Scan task in the list of tasks on the Show assistant panel.

Run your pipeline

When you are done making the changes to the file, click Save and Run.

See the results

To display the Qodana report summary in Azure DevOps, install Microsoft DevLabs’ SARIF SAST Scans Tab extension. Once installation is done, go to the Pipelines tab, select the pipeline being run and analyzed, and look at the Scans tab for more information about the quality of your code.

With the Qodana for Azure Pipelines extension, you will be able to easily integrate Qodana into your Azure DevOps pipeline and start seeing the analytics the first time your code is checked.

If you have any questions or suggestions about Qodana, post a comment here, tag us on Twitter or contact us at qodana-support@jetbrains.com.

Your Qodana team

Cut Time on Code Reviews and Project Planning With Static Analysis

Kate — Thu, 27 Jan 2022 11:00:07 +0000

When you’re tired of endless code reviews and debugging, you may start wondering if there are ways to automate tedious tasks without it backfiring on you later in development. If this is something you or your team are interested in, you may want to take a closer look at server-side static analysis. How will you benefit from adding yet another step in the project lifecycle, especially in the age of smart IDEs? What kinds of tasks can you delegate to a static analysis tool? Read this blog post to find the answers to these questions and more!

Automate code reviews
Stay confident with external contributions
Slash time spent on project planning
Static analysis with Qodana in your project lifecycle

Automate code reviews

According to the Active State Developer Survey 2019, 61.5% of developers spend four hours or less a day writing code. One of the tasks contributing to the non-coding time is code reviews. The main goal of this process is a direct discovery of quality problems. In many projects, quality means:

1) flawless business logic implementation;

2) elements related to the maintainability of the code: design pattern, naming strategies, code style, etc.

If the process is purely manual, the reviewer should care about both aspects. It can be error-prone and time-consuming. For example, try to spot a deficiency in the code related to the regular expression:

It couldn’t be easy for you, but it’s a trivial task for a static analysis tool. It’s just one example. You can automate many checks for unused imports, dead code, duplicates, spelling problems, formatting issues, and many more – any rules of your choice. For example, if you use TODO’s in the comment, you can automatically check that each of them contains a reference to the issue tracker, as some teams in JetBrains do.

Those checks configured in the editor guide developers, but this guidance becomes a mandatory rule with the server-side static analysis. The server-side quality gate will ensure the code meets specific standards before it moves onto the next phase, like manual code review or deployment to production. The author and the reviewer will spend less time in the feedback loop. Also, you will have a track record for proofs and further analysis.

Stay confident with external contributions

Code reviewing is good practice, even if all team members are equally skilled, accurate, and have a shared understanding of the code quality. Even professional climbers need belays, don’t they? And a belay becomes vital if you don’t know the actual skill level of the contributor. Accepting an external contribution to your project is precisely the case when you need an additional guarantee that the contributor follows your guidelines. It can be a pull request to the open-source project or tasks you delegate to the subcontractor – the automatic code review will perform routine checks so you can focus on business value.

Slash time spent on project planning

With server-side static analysis, you can review the created code and plan your code evolution steps. Imagine you want to switch to a newer version of the language or framework. If you’re lucky, you update your dependencies, and your project is up and running. In a less fortunate scenario, you update your dependency, and the IDE highlights tons of places you need to update.

For big projects, the number of changes could be so large that you will need several people to succeed. How will you split the work between them? Static analysis platforms can build a report to split the work between people and estimate the outcome. This goes for any refactoring you need for your code. For example, with checks based on structural searches, you can evaluate all places that require your attention. Technically, this analysis can be done on the developer’s machine, but there will be no option to share the list of issues and track the progress with others.

Static analysis with Qodana in your project lifecycle

Qodana, the code quality platform from JetBrains, empowers you and your team to leverage the benefits of a static analysis tool while integrating with your favorite CI/CD pipelines – TeamCity, GitLab, GitHub, and others. The picture below illustrates a typical software build process employed during the software development life cycle and how Qodana can be integrated with this process.

To get started with Qodana, check our previous blog post for detailed instructions, or download the version of the components that are suitable for your technology stack:

Visit jetbrains.com/qodana for more information. We would be grateful for any feedback you might have, and all ideas are welcome! Contact us at qodana-support@jetbrains.com or via our issue tracker.

Your Qodana team

Better Late Than Never, or New Year’s Resolutions with Qodana

Viktor Tiulpin — Tue, 28 Dec 2021 12:00:00 +0000

Even before we started to work on Qodana, we knew from our own experience and user interviews that it’s hard to add static analysis to a project, which leads people to postpone this decision.

// Detect dark theme var iframe = document.getElementById('tweet-1475799581434781699-996'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1475799581434781699&theme=dark" }

If you join a project with established code quality procedures, you can just follow the rules. If you start a shiny new project, you can pick any set of rules you want. This option has its pitfalls, but at least you know that your code meets your own standards from the beginning.

In contrast, if you join or work for a project where quality gates are not yet part of the process, being pressured to implement them could be a heartbreaking experience! We’ve felt it ourselves, and heard from many users who opened up in interviews: implementing the appropriate gateways can be a bumpy road.

Most people we talked to encountered issues with the following:

Figuring out what kind of rules to apply
Determining what to do with the existing issues
Identifying how to make all of this sustainable

Our goal with Qodana has always been to provide a pleasant experience for those who decide to have quality gates, and we’ve developed two new features to further this goal:

Project setup wizard, which lets you tailor your analysis configuration further based on the initial results.
Technical debt (or baseline), which lets you mark a given state of the project as initial and track further changes.

If you have been thinking about using quality gates for your project but haven’t known where to start, this post is right for you. You don’t need to wait until the first week of January to adopt your New Year’s resolution: you can get started now, and make your life in the new year easier.

Start with a local run and create a baseline

Let’s start with your local machine. If you use a JetBrains IDE and are familiar with code inspection profiles, you can re-use them in your Qodana run. If you are unsure of what server-side analysis fits your project best, you can start with Qodana’s default options. We introduced three-phase analysis precisely for this case.

Follow these steps to run Qodana on your project:

Pick the proper Qodana linter for your project’s technology stack and pull its image:

docker pull jetbrains/qodana-<linter>

Options include qodana-jvm, qodana-jvm-android, qodana-php, and so on.

Perform the first run:

docker run --rm -it -p 8080:8080 \
  -v <project-root-directory>/:/data/project/ \
  jetbrains/qodana-<linter> --show-report

Your project’s working folder likely has all the required dependencies in place, so you don’t need to perform any additional steps for the analysis to succeed. In cases when you’ve just cloned the repository and haven’t previously worked in the editor on this machine, depending on the project technology, either Qodana will do everything on its own or you will need to take one extra step to download project dependencies. For more details about this step, please check out the corresponding section in our documentation.

After the analysis is complete, you will see an invitation to check the results. Open Qodana UI in your browser using this link: http://localhost:8080.

You will see a page that looks like the example below.

During this first run, Qodana analyzes your project using vital checks only. Non-vital checks and folders containing non-vital code, such as the Tests folder, are ignored. Qodana also reports any conditions that could affect the truthfulness or completeness of the results. For example, if your project relies on external resources or generated code that is unavailable during the analysis, the final results could be compromised. Qodana notifies you about such suspicious results. We encourage you to follow the guidance during project setup and tune the configuration. After the first run, everything you need will be at hand. You can review every problem in the left-hand panel, and you will see immediately how your adjustments affect the number of issues you need to work on.

Our favorite step is the third one – putting all the detected problems into a baseline.

Why put everything in a technical debt (baseline)? Well, bringing the number of problems in your code down to zero is quite simple, really: first, fix all existing issues; second, ensure no new problems appear over time. The second part may be easier than the first one, and by using the baseline, we set the current project state as the initial one and only track new issues that appear.

The last step in the project setup is downloading two files: qodana.yaml and qodana.sarif.json. Just place them into your project folder, and be sure to copy the suggested Docker command.

A local run with the baseline enabled

Now return to your console and run Qodana again using this command:

docker run --rm -it -p 8080:8080 \
  -v <project-root-directory>:/data/project \
  jetbrains/qodana-<linter> --show-report \ 
  --baseline=baseline.sarif.json

Please ensure you use the proper Docker image name.

You will see something similar to the example below. Qodana now treats all of the previously discovered issues as the baseline and does not report them again.

Add even more checks

At this point, you are ready for the next step – setting the quality gate in your CI. If you want to get started with that right away, feel free to jump right to the Quality gate section of this post.

But if you are feeling adventurous, you can examine the suggestions Qodana prepared for you, and perhaps enable even more checks. Use the Problem examples dialog to see the checks we suggest, as well as some examples in your codebase that need improvement according to those rules. If you find them appropriate, turn them on, download the updated qodana.yaml file to the project root folder, and run Qodana locally again to perform the same triage using even more checks.

You can repeat the previous steps again and again, thereby tailoring your configuration further.

When you are happy with what you see locally – it’s time to set a quality gate for your CI pipeline.

Quality gate for the CI pipeline

One good thing about Qodana is that you can add it to any CI platform. But since it would be hard to cover all integration-related nuances in a single blog post, we will describe its integration with GitHub Actions. The process of setting up quality gates is very similar in all other CI platforms, too, with the exception of TeamCity. In TeamCity, we would suggest you use our dedicated plugin.

So, if you use GitHub Actions as your main CI platform, follow these steps to set up quality gates:

Add qodana.yaml and qodana.sarif.json to your VCS. If you find qodana.sarif.json is too big to be placed in your VCS, you can store it anywhere it is accessible for your GitHub Actions.
Add the Qodana GitHub Action to your workflow by following the instructions in our documentation.
Set the workflow to run on pull_request events that target the main branch.

on:
  pull_request:
    branches:
    - main

Add the fail-threshold option with a value of 0 to the Qodana Action, as well as branch protection rules to any branch you want to protect. We suggest starting with the main branch.

For more information about branch protection rules, refer to the GitHub Documentation.

Now you are all set! Your changes will be checked by Qodana so they will meet your standards. You can use this action as a proper quality gate. For example, you can check incoming pull requests and merge only those whose quality is up to your standards. If your most common scenario involves developing in branches, you can add this action to make sure the whole branch is checked before being merged into the main branch. Actually, you can include a Qodana Action in any part of your pipeline and use the produced artifacts and resulting exit code as the basis for further decisions.

And if, like us, you like making New Year’s resolutions, you can make a plan to work on the issues from the baseline one step at a time in 2022. Qodana UI will help you plan out this work, e.g. you can choose issues to be fixed by category, or folder, or just one-by-one.

When you reach zero issues in the actual list and the baseline, it will be time to go to the ‘next level’. You can turn to Qodana’s suggestions for inspiration, or study the whole list of checks to add more of them to your profile.

By the way, Qodana is extensible: you can create your own checks. We will cover this topic in a dedicated blogpost at the beginning of next year.

Try it now and improve your code

Check out the website to download the version of the components that’s suitable for your technology stack. Some of them have already reached stable releases, and some are available under an Early Access Program (EAP). Don’t wait to set yourself up to meet your code quality goals in the new year. Future you will thank you!

Feedback

We would be grateful for any feedback you have, and all ideas are welcome! Contact us at qodana-support@jetbrains.com or via our issue tracker.

Your JetBrains Qodana Team

The Drive to Develop

Forem: JetBrains Qodana

Qodana Is Out Of Preview With First-Class JetBrains IDE Integration

What’s new in Qodana 2023.2

1. Server-side analysis by Qodana is now fully integrated with JetBrains IDEs 2023.2

2. Code coverage support

3. Vulnerability checker based on the Checkmarx data

4. Quick-fixes (experimental)

Qodana features beyond the 2023.2 release

2500+ code inspections – exclusive Qodana inspections included

Interactive inspection reports and dashboards

Cloud-based overview of reports

The baseline for getting your technical debt under control

Third-party license audit

Inspection constructor

Qodana pricing that makes managers say “Wow”

How to get started with Qodana?

Secure Your PHP Code With Taint Analysis by Qodana

What is taint analysis?

How taint analysis works in Qodana

Example #1. SQL injection

Example #2. XSS problem

Conclusion

Qodana and IntelliJ IDEA: How a Code Quality Platform Streamlined the Localization of an IDE

The challenge: isolate 13,000 hard-coded strings and monitor progress effectively

The solution: automated code inspection for hard-coded string literals

The key outcomes

Announcing the Preview for Qodana Cloud, a One-Stop-Shop for All Your Code Quality Insights!

How Qodana Cloud can complement your projects

Get deeper insights into your projects’ trends

Open problems detected by Qodana in your favorite IDE

Plan your work better

Choose the dark or the light side

What’s coming next?

How to get started with Qodana Cloud

Project setup

Qodana 2022.3 EAP Is Out: Qodana for .NET and Go and 100+ New Inspections

Qodana for .NET

Qodana for Go

New inspections

Java and Kotlin inspections

Python inspections

Qodana 2022.2 Is Available: 50+ New Inspections and CircleCI Orb

More CIs to run Qodana with

New inspections

Regular expressions

Simplified regular expressions

Suspicious backreferences

Redundant \d, [:digit:], or \D class elements

Markdown support

Incorrectly numbered list items

Java, Kotlin, and Android inspections

JUnit: Malformed Declaration

JUnit: Unconstructable TestCase

PHP inspections

Probable bug: Number ranges mismatch

Documentation: Type tag without variable name

Blade: Parse error due to unpaired parentheses in string literals

Qodana 2022.1 Is Available

License audit

PHP inspections

Java and Kotlin inspections

Why Do Testers Need CI/CD?

Running tests automatically

Quality control using quality gates

What quality checks can be included in CI/CD?

Examples of tools to incorporate in quality checks

Shaping the release process

Introducing Qodana for Azure Pipelines

Install Qodana for Azure Pipelines

Configure Qodana to analyze your code

Set up a pipeline that integrates with Qodana

​​Run your pipeline

See the results

Cut Time on Code Reviews and Project Planning With Static Analysis

Automate code reviews

Stay confident with external contributions

Slash time spent on project planning

Static analysis with Qodana in your project lifecycle

Better Late Than Never, or New Year’s Resolutions with Qodana

Start with a local run and create a baseline

Redundant `\d`, `[:digit:]`, or `\D` class elements

Run your pipeline