CodeClimate Automated Code Review Setup for CI

A CI pipeline that still calls the old CodeClimate Quality API will fail, not intermittently but as a matter of course, because that API stopped responding on July 18, 2025. Any build script, status check, or coverage upload step written against the legacy infrastructure now points at a dead endpoint. This is not a routine version bump that left old commands slightly deprecated but still working. Qlty now runs at docs.codeclimate.com, and it's a different platform, with its own command-line tool, its own configuration file format, and its own cloud service. A team that searches "CodeClimate CI setup" today is likely to land on a guide written before 2025, one that walks through steps built for a product whose servers no longer answer, and the first job of any honest setup guide is to say so before it says anything else.

What CodeClimate Quality does

CodeClimate Quality worked by reading every file in a codebase and assigning it a maintainability grade from A to F, built from static analysis of complexity, duplication, and structural problems in the code, then posting those grades directly into pull requests. So reviewers got a quick, consistent signal about whether a change made the codebase easier or harder to maintain, and they didn't have to reason through cyclomatic complexity or duplicate logic by hand. The design from the start centered on tying that analysis into CI: measuring test coverage on every build, scanning for security vulnerabilities, and flagging bad practices and likely bugs before code merged. A separate product called Velocity, aimed at engineering leadership, tracked metrics like cycle time, throughput, and deployment frequency; that tool now sits under Qlty Software as a distinct offering and has nothing to do with the CI setup this guide covers. What matters for CI purposes is narrower: teams wired CodeClimate into their pipelines because it turned code quality and test coverage into something a build could enforce automatically, not something a human reviewer had to catch by eye. Losing that automated layer, or running it against infrastructure that no longer exists, means losing the enforcement, not just the convenience.

The legacy setup: the.codeclimate.yml and cc-test-reporter pattern

The setup before migration split cleanly into two parts, so a team trying to recognize what it's currently running has to understand both. The first part was static analysis configuration, handled through a file called.codeclimate.yml committed to the root of the repository. That file had five possible root sections: version, prepare, checks, plugins, and exclude_patterns. Only the plugins and checks a team explicitly enabled in that file ran at all, which made the file the single, complete record of what analysis actually happened on a given repo.

The second part was test coverage reporting, and it worked differently: instead of a configuration file, it ran through a binary injected into the CI pipeline itself. Teams pulled a CC_TEST_REPORTER_ID from their project's Repo Settings page and set it as an environment variable in CI. The cc-test-reporter binary then ran at two points in the pipeline, once before the test suite ran and once after, and it stitched coverage data together around the actual test execution. If a repo carries a.codeclimate.yml file, a CC_TEST_REPORTER_ID variable, or calls to cc-test-reporter in its CI config, it's running this exact pattern, and every one of those pieces depends on an API that no longer responds. Any team that finds these artifacts in its pipeline needs to treat migration as immediate, not optional.

The current platform: Qlty Cloud and Qlty CLI

Qlty replaces the old platform with two components: Qlty Cloud, the hosted service that runs analysis, and Qlty CLI, the tool teams run locally and from CI. For a team setting up fresh, the practical difference is significant. Static analysis in Qlty Cloud runs automatically once a repo connects, so a new team can be up and running in minutes without touching CI configuration for that part of the workflow. But coverage uploading is separate, and it still needs explicit CI integration no matter how a team starts, so this guide repeats the distinction later.

Beyond the architecture, Qlty also brings you real functional gains over the platform it replaces. Security scanning is now built in, covering static analysis (SAST), infrastructure-as-code scanning (IaC), and software composition analysis (SCA), categories that previously required separate tools and separate configuration. Coverage reporting improved too: diff coverage, meaning coverage measured specifically on the lines a pull request changes, now highlights directly in the Qlty interface. The plugin system was rebuilt to run linters without Docker virtualization, which makes analysis faster and lets new linter versions reach users immediately instead of waiting on repackaged releases. On pricing, you get Qlty Cloud free for unlimited private contributors, a real shift from the per-repository or per-user pricing that governed the predecessor product. This is the baseline a team needs to understand before configuring anything, and the next section walks through how that configuration works.

How migration from.codeclimate.yml to Qlty works

Migration splits into two paths, and which one applies depends entirely on whether a repo already has a.codeclimate.yml file.

For repos that have one, Qlty attempts to reproduce the existing configuration at build time, a process powered by the command qlty config migrate. That reproduction is conservative: only the plugins and checks explicitly enabled in the old file get enabled under the new one. This is the point in migration that carries the most risk for established codebases, because there's no published guarantee that every legacy analysis engine has a direct Qlty equivalent, and configurations that were heavily customized over time are the ones most likely to see something drop out silently. A team running qlty config migrate needs to audit the resulting configuration against the old one, plugin by plugin, rather than assuming the migration captured everything.

For repos with no.codeclimate.yml at all, the path is simpler: running qlty init autogenerates a configuration at build time. Either way, committing the resulting.qlty/qlty.toml file to the repository matters for a reason that's easy to overlook: it keeps local runs of qlty check --all aligned with what Qlty Cloud actually does. If you don't check that file into git, local and cloud behavior can drift apart, so you may see different results running checks locally than CI does.

Authentication follows its own logic. For GitHub Actions, OIDC is the recommended method, because it's the most secure option and requires no management of long-lived tokens sitting in CI secrets. If you're on another CI provider, you need a coverage token instead, because OIDC support isn't universal across CI platforms.

Wiring test coverage reporting into CI under Qlty

Static analysis under Qlty Cloud runs on its own once you connect a repo, but you still have to get coverage data there yourself. Coverage has to be explicitly uploaded from CI every time, and a team that migrates its static analysis configuration but forgets this step will end up with working code analysis and broken, empty, or stale coverage reporting, a gap that's easy to miss because the rest of the pipeline looks fine.

The coverage gates map directly onto what CodeClimate used to offer, just under new names. The Qlty Diff Coverage commit status replaces the old codeclimate/diff-coverage check and enforces a minimum coverage threshold on the lines a pull request actually changes, configurable per project. The qlty coverage command replaces codeclimate/total-coverage, but it also adds a new setting, Total Coverage Variation, so you get finer control than the old total-coverage check gave you. On top of both, Qlty lets you configure PR gates that block a merge outright when new code comes in under the coverage threshold or when total coverage drops, so you get the same enforcement power the old setup had, routed through new commands and new status checks. Any team still watching for the old codeclimate/ status names in its branch protection rules needs to update those rules to the new Qlty equivalents, or the gate will simply never fire.

What a real migration looks like, the HybridCloudWorks example

HybridCloudWorks ran a migration that shows both sides of this transition at once, the configuration side and the coverage side, starting from a repo with no.qlty/ directory in git and no coverage reporting anywhere in CI. The team committed a.qlty/qlty.toml to align local checks with Qlty Cloud, then set up coverage uploads from CI separately for its frontend/ directory and its functions/ directory, so each stood as its own component rather than one forced, combined report. The coverage upload itself ran through qltysh/qlty-action/coverage@v2.3.0. Alongside this, the migration brought in a full set of security scanners under Qlty's bundled coverage: bandit, checkov, gitleaks, osv-scanner, radarlint-iac, trivy, trufflehog, and zizmor. That scanner list is the clearest evidence of what consolidation actually looks like in practice: tools that would otherwise have needed separate configuration, separate credentials, and separate CI steps now run under one platform, which is what eliminated what had been multi-tool sprawl in the pipeline.

Genuine trade-offs in the current setup teams should know about

Migration works, but three trade-offs are worth weighing honestly.

The first is plugin compatibility risk. Teams with heavily customized.codeclimate.yml files need to verify, engine by engine, that a Qlty equivalent exists before trusting qlty config migrate to have captured everything, since there's no published guarantee of full coverage across every legacy plugin. A regression here, a plugin that ran before migration and silently doesn't run after, can sit unnoticed for a long time if a team assumes the migration finished the job.

The second concerns the security layer's maturity. The consolidation argument, that bundling SAST, IaC scanning, and SCA into one platform solves the sprawl of managing separate tools, holds up concretely in the HybridCloudWorks case. But teams operating under strict security or compliance requirements may find that dedicated SAST tools, vendors that have invested specifically in this space, offer more mature rule sets and more developed compliance reporting than a platform that added security scanning as a newer feature layer. That doesn't make Qlty's security scanning unfit for purpose. So if you carry stringent audit or compliance obligations, you should check the specific rule sets and reporting formats you depend on before you retire a dedicated tool.

The third is the overall cost calculus. Before Qlty, getting static analysis, SAST, IaC scanning, and code coverage all running typically meant standing up and maintaining several separate tools, each with its own configuration and its own learning curve. Qlty Cloud's free tier for unlimited private contributors changes that math, and it now favors consolidation substantially. Even so, you should check whether the bundled security layer meets your compliance and rule-set requirements before you decommission anything you currently rely on. A free, consolidated platform is only a good trade if it covers what the dedicated tools were covering.

The setup checklist, what a complete Qlty CI integration requires today

A complete Qlty CI integration has four layers, and skipping any one leaves a gap that the old CodeClimate setup may have filled differently.

The first layer is the configuration file. Commit a.qlty/qlty.toml to the root of the repository. If migrating from an existing.codeclimate.yml, run qlty config migrate and then audit the resulting file against the original, checking specifically for plugins or checks that didn't carry over. If starting fresh with no prior configuration, run qlty init and review what it generates before treating it as final.

The second layer is authentication. Set up OIDC for GitHub Actions where you can, since it needs no long-lived token to manage and is the more secure option; if OIDC isn't available on your CI provider, configure a project coverage token instead.

The third layer is coverage upload, and you have to wire it explicitly in CI no matter how you configure static analysis, since Qlty Cloud running analysis on its own does nothing for coverage data. The fourth is the gate configuration itself: setting the Qlty Diff Coverage status and the qlty coverage total-coverage check to the thresholds a team actually wants enforced, and confirming branch protection rules reference the new status names rather than the old codeclimate/ checks that no longer exist. A team that works through all four layers has a setup that matches what CodeClimate used to provide, running on infrastructure that actually responds.