Qodana
The code quality platform for teams
How to Integrate Qodana Into TeamCity
There are many compelling reasons to use TeamCity as your CI server. Thanks to its out-of-the-box features, smart test management capabilities, and great scalability for enterprises, TeamCity offers a robust and reliable CI solution. But if you’re really looking to increase compliance and improve code quality and security, you can couple it with Qodana.
Integrating Qodana’s static code analysis can significantly improve the quality of your codebase and help you enforce better standards in your CI/CD pipeline. With built-in support through a dedicated Qodana build runner, it’s becoming increasingly easy to embed code quality checks directly into your development workflow.
In this post, we’ll explore how Qodana and TeamCity complement each other and how to get started with your integration process.
Table of Contents
Bringing Qodana into TeamCity
Qodana is available as a build runner within TeamCity, making it simple to incorporate static analysis into your existing builds. To get started, make sure that your project is built using a language supported by Qodana, such as Java, Kotlin, PHP, Python, JavaScript, TypeScript, Go, or C#.
Qodana is compatible with various IDEs and any CI pipeline, including all JetBrains IDEs (like IntelliJ IDEA and Rider), VS Code, and Visual Studio, as well as platforms like Jenkins and .NET. You can find a list of Qodana linters here.
If you’re running your own TeamCity agents, ensure that Docker is installed and accessible. For users of TeamCity Cloud with JetBrains-hosted agents, this is already set up for you.
It’s worth noting that Qodana doesn’t currently support Windows-based build agents in TeamCity.
Configuring Qodana in your build pipeline
Setting up Qodana in TeamCity is easy.
While the recommended and most straightforward approach is to place your `qodana.yaml` configuration file directly in the repository, Qodana also supports dynamic configuration through TeamCity’s command-line runner. This can be helpful in edge cases, for example, if your team needs to tailor inspections dynamically based on project type, team preferences, or environment.
That said, for most teams, using a versioned `qodana.yaml` file ensures consistency, clarity, and traceability across builds.
To learn how to set up dynamic configuration in TeamCity, view our response to this query.
Prefer something more visual? Explore Qodana’s code coverage reports in the TeamCity UI – no scripting required.
Step 1: In TeamCity, go to the configuration page of your build and add a new build step.
Step 2: Select the Qodana build runner, and then expand the advanced options to customize its behavior.
Step 3: Define the linter you’d like to use, specify a version, and point to either a default or custom inspection profile. If you’re using Qodana Cloud, you can also add a project token at this stage. This is required for commercial linters, but optional for community ones.
buildType {
steps {
qodana {
name = "Qodana analysis"
linter = jvm {
version = Qodana.JVMVersion.LATEST
}
inspectionProfile = embedded {
name = "qodana.starter"
}
cloudToken = "%qodana.cloud.token%"
additionalQodanaArguments = "--baseline qodana.sarif.json"
}
}
}
Optional step: For more granular control, you can configure things like a unique report ID, working directory, or whether Qodana reports should be visible under the Tests tab in TeamCity. There’s also support for advanced parameters, such as Docker arguments or additional Qodana CLI options.
For more detailed instructions and more on the function of each step, view the docs.
Quality gates and baseline comparisons
Quality gates are tools that let you stop code from being merged to the main branch if it doesn’t meet specific requirements, or if too severe or too many issues are flagged. If a quality gate condition fails, Qodana terminates using exit code 255, which makes a CI/CD workflow or pipeline fail.
Qodana makes it easy to set up quality gates that fail a build when the number of issues exceeds a set threshold. It also supports baseline functionality, which allows you to compare the current analysis results with a previous state. This helps identify new problems instead of flagging the same issues with every analysis.
Both of these features are configured using simple command-line arguments in the Qodana runner. There are various ways you can set this up. For example, you can create a quality gate that considers the number of problems before allowing code to be merged (more flexible settings are available in `qodana.yaml`):
failureConditions:
severityThresholds:
any: 10 # Total problems
critical: 5 # Critical and other severities
high: 5
moderate: 10
low: 20
info: 20
This combination of quality gates and baseline functionality can help your team avoid a crisis as well as unnecessary noise from legacy issues.
Custom configuration with scripts
If your project requires a custom inspection profile or specific exclusions, you can use a `qodana.yaml` file. You can either include this file in your repository or use a script in TeamCity to generate it on the fly.
Viewing results in TeamCity or Qodana Cloud
Once your build runs, Qodana offers flexible options for reviewing results. You can access detailed analysis directly in the Qodana tab within TeamCity, making it easy to spot issues alongside your other build diagnostics.
Alternatively, you can explore the results in Qodana Cloud, which provides a web-based dashboard with collaboration tools, history tracking, and integration with issue trackers.
Supporting pull requests and branch analysis
Qodana also works well in pull request workflows. The purpose of pull request analysis is to examine code changes in a pull request or merge request, detecting issues introduced or fixed by that specific change.
Qodana compares the current branch against the target branch (e.g. `main` or `develop`), and then it highlights issues only in the changed files or lines.
By configuring VCS triggers in TeamCity, you can analyze merge requests or specific branches before they’re integrated into your main codebase. This adds an essential layer of quality assurance to every code review.
Then baseline track new problems introduced over time by comparing the current analysis results with a previous “clean” state.
You can generate a baseline file, and in future runs, Qodana compares the current issues against this baseline. Only new issues (not present in the baseline) are reported as problems.
These approaches can be combined for better quality gates and enforcement.
TeamCity Cloud and Qodana Cloud for better quality software products
Integrating Qodana into your TeamCity pipeline gives you a solid foundation for a healthier codebase. With static analysis running automatically as part of your build process, you reduce the chance of bugs slipping through and can use Qodana to enforce quality as a team.
TeamCity and Qodana compliment each other, with TeamCity managing your builds with Qodana ensuring that your code is clean and something you can be proud of. Both help prevent future issues, and together, they offer an automated, and scalable approach to CI/CD – with built-in code quality from day one.
Frequently Asked Questions
How do I use Qodana to analyze .NET projects?
To analyze .NET projects, you can use the `qodana-dotnet` Docker image or the native solution based on Rider. There’s also a Community Edition available via the `qodana-cdnet` Docker image, but it’s better to use the trial version of a paid license for greater functionality.
Why is TeamCity often used with Qodana instead of other analyzers?
TeamCity and Qodana are both created by JetBrains, which means deep integration that’s not easily reproduced by competitors.
Where can I get assistance if I have an issue?
You can visit this TeamCity Support page or email Qodana Support.
Don’t have TeamCity? Click the button below to download it.
If you want to learn more about Qodana’s plans and pricing, see here.
Special thanks to Irina Khromova and Pavel Sher for their contributions to this post.
Subscribe to Qodana Blog updates
