> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qlty.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> New features, improvements, and fixes across Qlty Cloud and the Qlty CLI

<Update
  label="August 31, 2026"
  tags={["Cloud", "Coverage"]}
  rss={{
title: "Is the code your team is shipping well covered?",
description:
  "Total coverage is a lagging metric on a large Project. Diff coverage — the coverage of the lines a change touches — is a leading one, and every Project's Trends page now charts it week by week.",
}}
>
  ## Is the code your team is shipping well covered?

  Most coverage trend charts plot a Project's total coverage over time. That's valuable, but on a large project total coverage is a lagging metric: a real change in how a team tests takes a long time to make a meaningful mark on the total. Diff coverage — the coverage of the lines a change touches — is a leading one. If your team is covering the code it ships, diff coverage is high now, and total coverage trends upward over time.

  Every Project's **Trends** page now includes a **Diff Coverage** chart, showing how well tested the code you merged was, week by week. Diff coverage is plotted as a line, with the executable lines changed in each period as bars behind it, so you can tell a meaningful week from a quiet one. Ranges run from 1 month to 3 years.

  There's nothing to configure — the chart is built from the coverage you already upload on your default branch. See [Diff Coverage Over Time](/coverage/diff-coverage-trends) for details.
</Update>

<Update
  label="August 5, 2026"
  tags={["Cloud", "Plugins"]}
  rss={{
title: "Give your linters a token without committing it",
description:
  "Build Secrets are encrypted, per-project environment variables for your cloud builds — the API token a linter needs for a private registry, or a license key for a commercial tool. Add one under Project Settings, name it in the plugin's qlty.toml environment block, and Qlty passes it to that plugin and nowhere else.",
}}
>
  ## Build Secrets (beta)

  Some linters need a credential to do their job: an API token to reach a private package registry, a license key for a commercial tool. Until now, there was no way to hand one to a cloud build without committing it to your repository.

  **Build Secrets** are encrypted environment variables you set per project. Open **Project Settings → Secrets**, add a name and a value, and it's available to that project's builds. Values are write-only — once saved, a secret is encrypted and can never be read back, only rotated or deleted. The list shows names and timestamps, and only project admins can see or change it.

  Adding a secret doesn't hand it to every plugin. The Qlty CLI runs each plugin in a subprocess with a restricted environment and passes through only the variables that plugin's definition names, so you opt each plugin in from your `qlty.toml`:

  ```toml theme={"system"}
  [[plugins.definitions.foo.environment]]
  name = "BAR"
  value = "${env.BAR}"
  ```

  Secrets reach your plugins only while Qlty installs and runs them, and never reach builds for pull requests from forks.

  Build Secrets are in beta and rolled out per workspace — [contact Qlty Support](https://qlty.sh/contact/support) to request access. See [Build Secrets](/cloud/build-secrets) for details.
</Update>

<Update
  label="July 23, 2026"
  tags={["CLI", "Cloud", "Coverage"]}
  rss={{
title: "Coverage for pull requests that run only the tests they need",
description:
  "Tags have always handled partial test runs that report a predictable set of tests. Test optimization tools break that: they pick a different subset every build, so the coverage they report would be misleading, and our advice has been not to publish it at all. Selective Coverage makes those runs usable by overlaying the selected report on the pull request's diff. Now in beta.",
}}
>
  ## Selective Coverage on pull requests (beta)

  Qlty has always supported partial test runs through [tags](/coverage/tags). Publish your unit tests as `units` and that suite is tracked on its own, because a tag runs a predictable set of tests each time and every report for it is comparable to the last.

  Test optimization tools break that assumption. To keep pull request builds fast on a large codebase, they choose a different subset of tests for every build based on what the change touched. Each report covers a unique slice of the codebase, comparable to nothing before it, and to a coverage tool it looks like a sudden, dramatic drop. The coverage such a run reports would be misleading, so our recommendation has been not to publish it at all.

  **Selective Coverage** makes those runs usable by overlaying the selected report on the pull request's diff. Add `--selection` to `qlty coverage publish` in the builds that run a dynamically selected subset of your tests:

  <CodeGroup>
    ```bash Qlty CLI lines theme={"system"}
    qlty coverage publish --selection coverage/lcov.info
    ```

    ```yaml GitHub Action lines theme={"system"}
    - uses: qltysh/qlty-action/coverage@v2
      with:
        token: ${{ secrets.QLTY_COVERAGE_TOKEN }}
        files: coverage/lcov.info
        selected: true
    ```
  </CodeGroup>

  Qlty trusts a selected report for the lines it does cover — exactly what diff coverage needs — so the Diff Coverage commit status and PR comments work as usual. The Total Coverage status passes with "Not computable for select coverage" rather than a misleading percentage; total coverage metrics, component coverage, trends, and the file explorer are untouched; and a selected report is never used as the comparison base for another pull request.

  Selective Coverage is in beta and requires Qlty CLI v0.633.0, GitHub Action `qltysh/qlty-action` v2.3.0, or CircleCI orb `qltysh/qlty-orb` 0.1.2 — or newer. Publish full-suite coverage on your default branch to keep totals and baselines accurate. See [Selective Coverage](/coverage/selective-coverage) for details.
</Update>

<Update label="June 12, 2026" tags={["CLI", "Cloud", "Coverage", "Plugins"]}>
  ## Seat-based licensing

  Qlty Cloud now licenses Workspaces by **seats** instead of active contributors. A new **Seat Management** settings page lets admins assign seats to contributors and see how many are in use. See [Seats](/cloud/billing/seats) for details.

  ## Verified seat assignment

  When you assign a seat on the Seat Management page, Qlty now verifies the GitHub username exists before granting the seat. A confirmation dialog shows the account's avatar, name, and whether they belong to your GitHub organization, so you can catch typos and confirm you're assigning the right person. Non-existent accounts are rejected before any seat is used.

  ## Search when adding projects

  The Add Projects page now has a search box that filters across all accessible repositories server-side, so you no longer have to page through every repo to find one in a large Workspace.

  ## `--skip-source-fetch` for `qlty coverage publish`

  `qlty coverage publish` now accepts `--skip-source-fetch`, matching `qlty check` and `qlty fmt`. When set, the command skips fetching remote sources and falls back to the default configuration if a source is not cached locally. See [coverage publish](/cli/commands/coverage-publish) for details.

  ## VB.NET maintainability analysis

  The Qlty CLI now analyzes `.vb` files for maintainability — complexity, duplication, and code smells — with VB.NET's case-insensitive member semantics handled correctly.

  ## Scala maintainability analysis

  The Qlty CLI now analyzes Scala (including Scala 3) source files for maintainability — complexity, duplication, and code smells.

  ## Knip honors `.qlty/configs/`

  Fixed Knip not picking up a configuration file placed under `.qlty/configs/` in nested-package layouts. Qlty now passes the config path to Knip explicitly.

  ## RuboCop `AllCops: Exclude` now respected

  Qlty now passes `--force-exclusion` to RuboCop, so `AllCops: Exclude` patterns in your `.rubocop.yml` are honored even though Qlty invokes RuboCop with explicit file targets.

  ## editorconfig-checker findings no longer dropped

  Fixed a bug where `editorconfig-checker` results were silently discarded when the tool reported a `-1` line number for an issue it couldn't locate. All findings are now reported.
</Update>

<Update label="June 2, 2026" tags={["CLI", "Coverage"]}>
  ## Verified CLI downloads in GitHub Actions

  The Qlty GitHub Actions now verify the Qlty CLI's Sigstore attestation before running it. Each action checks the downloaded archive against its signed provenance using the GitHub CLI, giving your workflows tamper-evident assurance that the binary came from Qlty. Verification is automatic and uses your existing `${{ github.token }}`.

  See [Integrity Verification](/cli/integrity-verification) for details.

  ## More coverage formats in the GitHub Action

  The Qlty coverage GitHub Action now accepts `dotcover` and `xccov-json` as `format` values, so you can upload JetBrains dotCover and Xcode `xccov` JSON reports directly from your workflow without converting them first.

  See [Generating Coverage Data](/coverage/generating-data) for details.

  ## Node 24 runtime for GitHub Actions

  The Qlty GitHub Actions now run on the Node 24 runtime, clearing the deprecation warning GitHub showed for the older Node 20 runtime and keeping the actions on a supported runtime ahead of GitHub's automatic migration.

  ## Windows support for the fmt action

  The Qlty `fmt` GitHub Action now runs on Windows runners in addition to Linux and macOS, so Windows-based CI pipelines can auto-format code with Qlty.
</Update>

<Update label="April 15, 2026" tags={["CLI", "Cloud", "Coverage"]}>
  ## C and C++ language support

  Qlty now provides maintainability analysis for C and C++. This includes complexity, duplication, and code smells, available in both the Qlty CLI and Qlty Cloud. See [C / C++](/languages/c-cpp) for details.

  ## Travis CI push branch detection

  Travis CI users no longer need to set the branch name manually when uploading coverage. The Qlty CLI now detects the branch automatically on Travis push builds, the same way it already does for other CI providers.
</Update>

<Update label="April 9, 2026" tags={["Plugins"]}>
  ## editorconfig-checker plugin

  We've added a plugin for [editorconfig-checker](https://github.com/editorconfig-checker/editorconfig-checker), which verifies that your codebase follows the rules defined in `.editorconfig`.

  ```bash lines theme={"system"}
  qlty plugins enable editorconfig-checker
  ```
</Update>

<Update label="March 24, 2026" tags={["Plugins"]}>
  ## Spectral plugin

  We've added a plugin for [Spectral](https://github.com/stoplightio/spectral), a linter for OpenAPI and AsyncAPI specifications.

  ```bash lines theme={"system"}
  qlty plugins enable spectral
  ```
</Update>

<Update label="March 18, 2026" tags={["Plugins"]}>
  ## golangci-lint v2 support

  The Qlty plugin for [golangci-lint](https://golangci-lint.run/) now supports the v2 output format in addition to v1, so you can upgrade golangci-lint without losing report parsing.
</Update>

<Update label="March 17, 2026" tags={["CLI", "Coverage"]}>
  ## Client-side coverage summing

  The Qlty CLI can now sum multiple coverage reports on the client before upload, complementing our existing server-side coverage merging. This is useful in CI workflows that already collect multiple coverage files on a single machine.
</Update>

<Update label="March 5, 2026" tags={["Cloud"]}>
  ## Resync renamed repositories

  When a GitHub repository is renamed, you can now click a **Resync** button on the Add Project page to update Qlty's reference to the new repository name, keeping the Project's existing history and settings instead of having to re-add it from scratch.
</Update>

<Update label="February 14, 2026" tags={["CLI", "Plugins"]}>
  ## Python 3.13+ support

  The Qlty CLI now supports multiple Python runtime releases, enabling Python 3.13 and newer for plugins that require recent Python versions.
</Update>

<Update label="February 5, 2026" tags={["CLI"]}>
  ## On-demand source fetching

  You now have precise control over when private sources are loaded — useful in offline or air-gapped environments, and for pre-fetching sources once in CI before running multiple analyses. A new `qlty sources fetch` command fetches the sources defined in `qlty.toml` without running analysis, and a new `--skip-source-fetch` flag tells `qlty check` and `qlty fmt` to use what's already on disk.

  ```bash lines theme={"system"}
  qlty sources fetch
  qlty check --skip-source-fetch
  qlty fmt --skip-source-fetch
  ```
</Update>

<Update label="January 29, 2026" tags={["CLI"]}>
  ## SLSA provenance for installers and upgrades

  Qlty CLI installer scripts are now published with [SLSA](https://slsa.dev/) attestations, and the `qlty upgrade` command verifies SLSA provenance for new releases using the `gh` CLI. This adds an extra layer of supply-chain integrity to installations and upgrades.
</Update>

<Update label="January 26, 2026" tags={["Cloud"]}>
  ## Improved SAML re-authentication

  When a user accessing a Workspace with SAML enabled needs to re-authenticate, Qlty Cloud now surfaces a clearer re-authentication page with explicit instructions, rather than a generic error.
</Update>

<Update label="January 24, 2026" tags={["Cloud", "Coverage"]}>
  ## Always-available PR Coverage tab

  The Pull Request Coverage tab now renders even when a base coverage report is missing, so reviewers always have a coverage view to work from. When there is no base report, diff coverage is displayed as "N/A" rather than blocking the page.
</Update>

<Update label="January 20, 2026" tags={["Cloud", "Coverage"]}>
  ## Better missing coverage data messaging

  When a Project is missing expected coverage data, the Coverage page now displays a clearer message explaining what's missing and how to resolve it.
</Update>

<Update label="January 8, 2026" tags={["CLI"]}>
  ## HTTPS required for all outgoing requests

  The Qlty CLI now requires HTTPS for all outgoing HTTP requests, including source fetching and tool downloads. All network activity from the CLI is encrypted in transit.
</Update>

<Update label="December 26, 2025" tags={["Coverage"]}>
  ## Jenkins CI auto-detection

  We now support automatic detection of build metadata from Jenkins. Uploading coverage from a Jenkins build only requires the path to the coverage data file. See [setting up coverage with Jenkins](/coverage/ci) for the full walkthrough.

  ```shell lines theme={"system"}
  qlty coverage publish coverage.lcov
  ```
</Update>

<Update label="December 19, 2025" tags={["Cloud", "Coverage"]}>
  ## Coverage page redesign

  A clearer view of how a pull request moves your coverage. The Project Coverage page has been rebuilt from the ground up, with:

  * Improved stats cards
  * A Files Changed tab with rendered file diffs
  * A Components tab showing per-Component coverage for the pull request
  * A collapsible sidebar with coverage comparison details
</Update>

<Update label="December 5–12, 2025" tags={["Coverage"]}>
  ## Coverage summary comment improvements

  Coverage summary comments on pull requests have been redesigned. The new comment includes:

  * An updated rating display
  * A **Modified Components** section showing which Components changed in the pull request
  * An **AI prompt** section with a ready-to-paste prompt for your AI coding agent to write the missing tests
  * The Qlty header image and clearer formatting
</Update>

<Update label="December 10–12, 2025" tags={["CLI", "Coverage"]}>
  ## More coverage formats supported

  The Qlty CLI now ingests two more coverage report variants without any conversion step:

  * Apple's `xccov-json` format produced by `xccov` from Xcode coverage data
  * JaCoCo reports containing `<group>` elements, the standard output for multi-module Maven and Gradle projects
</Update>

<Update label="December 1–4, 2025" tags={["Cloud", "Coverage"]}>
  ## Coverage Report page

  Full visibility into how each commit's coverage report was built — and a way to clean it up when something goes wrong. Qlty Cloud now includes a Coverage Report details page for each commit, showing summary metrics and every upload that contributed to the report. Project admins can also delete individual reports or uploads from Coverage Settings when a bad upload needs to be removed.
</Update>

<Update label="December 1, 2025" tags={["Cloud"]}>
  ## Maintainability shown as effort duration

  Maintainability is now displayed as estimated remediation effort (e.g. "2h 30m") in addition to issue counts, making it easier to compare projects and plan remediation work.
</Update>

<Update label="November 21, 2025" tags={["Coverage"]}>
  ## Bitrise CI auto-detection

  We now support automatic detection of build metadata from Bitrise. Uploading coverage from a Bitrise build only requires the path to the coverage data file.

  ```shell lines theme={"system"}
  qlty coverage publish coverage.lcov
  ```
</Update>

<Update label="October 28, 2025" tags={["CLI"]}>
  ## Configuration typo warnings

  The Qlty CLI now emits warnings when your `qlty.toml` contains unexpected attributes, helping you catch typos and outdated configuration syntax before they silently change your analysis.
</Update>

<Update label="October 22, 2025" tags={["Cloud"]}>
  ## API rate limiting

  Qlty API requests are now rate limited to protect service availability for all users. Clients that exceed the limit receive a `429 Too Many Requests` response with standard rate-limit headers, so your client can back off cleanly.
</Update>

<Update label="October 16, 2025" tags={["CLI", "Coverage"]}>
  ## Automatic path fixing for coverage

  `qlty coverage publish` now automatically detects and corrects common path mismatches between coverage reports and the repository, including paths produced inside Docker containers and CI runners. This works in addition to the explicit `--add-prefix` and `--strip-prefix` options. See [Path Fixing](/coverage/path-fixing) for details.
</Update>

<Update label="October 9, 2025" tags={["CLI", "Plugins"]}>
  ## Install-only mode

  `qlty check` now supports an `--install-only` flag that installs the plugins required by your configuration without running them. Use it to warm caches in CI so the analysis step runs faster on every build.
</Update>

<Update label="October 3, 2025" tags={["Cloud", "Coverage"]}>
  ## Onboarding flow

  We've shipped an updated onboarding flow for new users and new Workspaces, walking through GitHub installation, Project selection, and coverage setup.
</Update>

<Update label="September 15, 2025" tags={["CLI"]}>
  ## Coding with AI agents

  We've published a new guide on [coding with AI agents](/cli/coding-with-ai-agents) that documents recommended patterns for using the Qlty CLI with Claude Code, Cursor, GitHub Copilot, OpenAI Codex, and other agents that can run shell commands.
</Update>

<Update label="September 14, 2025" tags={["Cloud", "Coverage"]}>
  ## Applications

  For teams that ship a single product across several repositories, Applications give you one view of code quality at the product level. Group related Projects together at the Workspace level and see aggregated maintainability, duplication, security, and coverage metrics across all of them.

  Enable Applications from **Settings > Features**, then assign Projects from each Project's **Settings > General**. See the [Applications documentation](/cloud/applications) for details.

  ## Churn view in Project Hotspots

  The Project Hotspots page now includes a churn view that combines maintainability issues with file change frequency to surface the files most likely to benefit from refactoring.
</Update>

<Update label="September 9, 2025" tags={["Cloud"]}>
  ## Self-service Workspace deletion

  Workspace Owners can now delete their own Workspace directly from Workspace Settings, without needing to contact support.
</Update>

<Update label="September 5, 2025" tags={["Cloud"]}>
  ## Improved Projects index

  The Workspace Projects page now supports server-side sorting, a column picker, and shows the timestamp of the last build for each Project.
</Update>

<Update label="September 4, 2025" tags={["Cloud"]}>
  ## Components

  Track per-team or per-service code quality without splitting your repo. Qlty Cloud now supports Components, which let you group files inside a Project (for example, by service, package, or directory) and view maintainability metrics for each group independently.

  Components are particularly useful for monorepos and modular codebases. Configure them from your Project's settings.
</Update>

<Update label="August 29, 2025" tags={["Cloud"]}>
  ## Workspace Activation page

  A new Activation page in Workspace Settings shows which Projects are activated, with sorting, filtering, and pagination — making it easier to manage Qlty across large organizations.
</Update>

<Update label="August 27, 2025" tags={["Plugins"]}>
  ## ktlint plugin

  We've added a plugin for [ktlint](https://github.com/pinterest/ktlint), an anti-bikeshedding Kotlin linter and formatter.

  ```bash lines theme={"system"}
  qlty plugins enable ktlint
  ```
</Update>

<Update label="August 21, 2025" tags={["Cloud"]}>
  ## Delegated billing

  Delegated billing lets a single Workspace manage payment and subscription for one or more other Workspaces. This is useful for agencies, consultancies, and parent organizations that pay for multiple Workspaces.
</Update>

<Update label="August 20, 2025" tags={["CLI", "Coverage"]}>
  ## JaCoCo source path override

  Java and Kotlin projects with non-standard source layouts can now point JaCoCo coverage uploads at the right directories by setting the `JACOCO_SOURCE_PATH` environment variable before running `qlty coverage publish`.
</Update>

<Update label="August 18, 2025" tags={["Cloud"]}>
  ## Workspace Manager permissions

  A new Workspace Manager role lets you delegate workspace-level administration to specific users without granting them GitHub Organization Owner permissions. See [User Permissions](/cloud/permissions) for the full permissions matrix.
</Update>

<Update label="August 11, 2025" tags={["CLI"]}>
  ## GitHub Merge Queue support

  The Qlty CLI now has initial support for GitHub Merge Queues. We also detect merge groups across any CI provider that listens to GitHub push events (#2320).
</Update>

<Update label="August 5, 2025" tags={["Cloud"]}>
  ## Analysis Minutes progress bar

  Workspace billing pages now show an Analysis Minutes progress bar and a usage breakdown table so you can see at a glance how your build minutes are being consumed.
</Update>

<Update label="August 4, 2025" tags={["CLI", "Cloud", "Coverage", "Plugins"]}>
  ## Workspace pausing

  You can now pause a Workspace from its settings page. While paused, Qlty stops running analysis and coverage reporting — useful while a repository is dormant or when you need to temporarily halt billable usage without deleting the Workspace.

  ## Default coverage validation

  `qlty coverage publish` now validates coverage reports by default, catching path mismatches and malformed reports before they corrupt your metrics. If you need to temporarily disable validation while fixing a report, use `--no-validate`:

  ```bash lines theme={"system"}
  qlty coverage publish --no-validate coverage.lcov
  ```

  See [Path Fixing](/coverage/path-fixing) for details.

  ## zizmor plugin

  We've added a plugin for [zizmor](https://github.com/woodruffw/zizmor), a security analyzer for GitHub Actions workflows.

  ```bash lines theme={"system"}
  qlty plugins enable zizmor
  ```
</Update>

<Update label="July 17, 2025" tags={["CLI", "Coverage", "Plugins"]}>
  ## Coverprofile parser

  The Qlty CLI now parses Go's native `cover.out` (Coverprofile) format. You can upload Go coverage data without converting to another format first.

  ```bash lines theme={"system"}
  qlty coverage publish cover.out
  ```

  ## Faster debugging of plugin install failures

  When a plugin fails to install, the Qlty CLI now surfaces the installation log directly in the main build log and points you to the full debug log on disk. No more guessing why a CI build broke during plugin setup.
</Update>

<Update label="July 7, 2025" tags={["Cloud"]}>
  ## Project Hotspots

  Qlty Cloud now includes a Hotspots page on every Project. Hotspots highlight the files most likely to need attention by combining maintainability, duplication, and (in later updates) churn data.

  ## Named API access tokens

  API access tokens now have a name, description, and optional expiration date. You can manage your tokens from your user settings page. Existing tokens will continue to work — you can add metadata to them or rotate them at any time.
</Update>

<Update label="July 4, 2025" tags={["Cloud", "Coverage"]}>
  ## Project Trends

  Qlty Cloud now includes a Trends tab on every Project. The Trends view visualizes how key quality metrics — including maintainability, duplication, and code coverage — change over time on your default branch.
</Update>

<Update label="June 25, 2025" tags={["Cloud", "Coverage"]}>
  ## Qlty API (beta)

  Pull Qlty data into your own tools. The Qlty API is now in beta, with endpoints for listing and reading Projects and for reading analysis Issues for a Project. Authenticate with a personal access token from your user settings to query any Workspace you can access. See the [API Reference](/api/introduction) for details.

  ## Coverage Diff commit status setting

  A new workspace-level setting controls whether Qlty posts a separate **Coverage Diff** commit status to GitHub (in addition to the existing Coverage status). Toggle it from Workspace Settings if your branch protection rules don't expect this status.
</Update>

<Update label="June 24, 2025" tags={["CLI", "Coverage"]}>
  ## Git-free coverage publishing

  You can now publish coverage from environments that don't have a Git working directory — for example, containers that only carry the test artifacts. Pass `--override-commit-time` to `qlty coverage publish` to skip Git detection.
</Update>

<Update label="June 11, 2025" tags={["CLI", "Coverage"]}>
  ## dotCover format support

  The Qlty CLI now parses [dotCover](https://www.jetbrains.com/dotcover/) reports for .NET projects, in addition to the formats we already supported.

  ```bash lines theme={"system"}
  qlty coverage publish coverage.dcvr
  ```
</Update>

<Update label="June 2, 2025" tags={["CLI"]}>
  ## SARIF output for `qlty smells`

  `qlty smells` now supports the `--sarif` flag, joining `qlty check` in producing standardized [SARIF](https://sarifweb.azurewebsites.net/) output for integration with other tools.

  ```bash lines theme={"system"}
  qlty smells --sarif
  ```
</Update>

<Update label="May 5, 2025" tags={["Cloud"]}>
  ## Qlty Cloud Enterprise plan

  We've added a new Enterprise plan for Qlty Cloud, tailored for organizations with advanced needs. This plan includes everything in our Pro plan, plus more analysis minutes and additional features to enhance your experience:

  * Priority support with a SLA
  * Named account manager available through a private Slack channel
  * Consolidated billing for multiple GitHub organizations
  * Payment via invoices (including ACH and wire transfer)
  * Migration assistance
  * Terms of Service customization

  Learn more about the [Enterprise plan](https://qlty.sh/pricing) and how it can benefit your organization.
</Update>

<Update label="May 2, 2025" tags={["CLI", "Cloud", "Coverage"]}>
  ## Server-side coverage merging

  We're proud to announce a long-requested feature: Server-side coverage merging!

  In testing workflows which involve multiple test suites, parallelization, or multiple programming languages it is common to produce multiple code coveragate data files. Previously, we only offered client-side coverage merging which required that all of the coverage data was available on the same filesystem and sent to the server as a single upload.

  In many scenarios, client-side merging was cumbersome and required uploading and downloading files from shared storage (like S3 or GitHub Actions artifacts). Also, visibility into the process was limited, resulting in a poor debugging experience if something went wrong.

  The addition of server-side merging significantly simplifies the set up of code coverage reporting in complex CI workflows, and enabled full visibility into the process from Qlty Cloud. To ensure accurate reporting, we delay posting coverage reports to GitHub until all of the coverage data is received.

  <CodeGroup>
    ```yaml GitHub Action lines theme={"system"}
    # Upload each coverage file separately
    - uses: qltysh/qlty-action/coverage@v1
      with:
        oidc: true
        files: coverage/coverage1.lcov
        incomplete: true

    - uses: qltysh/qlty-action/coverage@v1
      with:
      oidc: true
      files: coverage/coverage2.lcov
      incomplete: true

    # Tell Qlty all parts have been uploaded

    $ qlty coverage complete

    ```

    ```bash Qlty CLI lines theme={"system"}
    # Upload each coverage file separately
    qlty coverage publish --incomplete coverage/coverage1.lcov
    qlty coverage publish --incomplete coverage/coverage2.lcov

    # Tell Qlty all parts have been uploaded
    qlty coverage complete
    ```
  </CodeGroup>

  We support Learn more about [coverage merging](/coverage/merging) in our documentation.
</Update>

<Update label="May 1, 2025" tags={["Cloud", "Coverage", "Plugins"]}>
  ## Qlty Cloud is out of beta

  We're excited to announce that we have completed our beta phase for Qlty Cloud and have advanced it to GA status!

  Thank you to everyone who provided feedback and helped us improve the product during the beta period. We are proud to have made significant improvements based on your input, including:

  * Server-side coverage merging
  * OpenID Connect (OIDC) authentication for easier coverage setup
  * Expanded support for programming languages like C# and Swift
  * Additional plugins, bringing our total to 70+
  * Significant performance improvements to the Qlty Cloud website
  * Many bug fixes and improvements to the debugging experience

  With Qlty Cloud now in GA, we'll be activating our billing system for all users by the end of the month. We offer a plan which is free for unlimited, private contributors and have paid plans with additional features and build minutes. Learn more on our [pricing page](https://qlty.sh/pricing).

  We look forward to continuing to iterate Qlty rapidly to deliver code quality and coverage done right.
</Update>

<Update label="April 30, 2025" tags={["Cloud", "Plugins"]}>
  ## StringsLint plugin

  We've added a plugin for [StringsLint](https://github.com/dral3x/StringsLint) which is ensures that localized strings in a Swift project are complete and never unused.

  StringsLint runs on macOS and targets files with the extensions `*.strings`, `*.stringsdict`, `*.swift`, `*.m`, `*.xib`, and `*.storyboard`. You can enable it using the Qlty CI:

  ```bash lines theme={"system"}
  qlty plugins enable stringslint
  ```

  <Note icon="terminal">
    StringsLint only runs on macOS and is not available on Qlty Cloud which runs on Linux.
  </Note>

  ## SwiftFormat plugin

  We've added a plugin for [SwiftFormat](https://github.com/swiftlang/swift-format), the official auto-formatter for Swift. This auto-formatter targets Swift files, runs on macOS, and can be enabled using the Qlty CI:

  ```bash lines theme={"system"}
  qlty plugins enable swiftformat
  ```

  <Note icon="terminal">
    SwiftFormat only runs on macOS and is not available on Qlty Cloud which runs on Linux.
  </Note>
</Update>

<Update label="April 28, 2025" tags={["Cloud"]}>
  ## Cloud authentication improvements

  We've significantly improved the latency of most web pages by using a short-lived caching strategy for our GitHub authorization checks. Navigating around the website should feel faster. (The exception is the Dashboard, which we will be optimizing soon.)

  Also, for organizations that use SAML on GitHub, we now detect when GitHub requires SAML re-authorization and use that information to render better error messages. Users accessing a GitHub organization with SAML enabled need to re-authorize occasionaly, and we now show a message with instructions on how to do that.
</Update>

<Update label="April 27, 2025" tags={["CLI", "Plugins"]}>
  ## Out-of-the-box linter configs

  The Qlty CLI now provides out-of-the-box linter configurations for several popular linters. These linter configuration files are copied into your project when you run `qlty init` or `qlty plugins enable PLUGIN`.

  This allows you to quickly set up your project with sensible defaults without needing to create a configuration file manually. Once the configuration files are in place, you can customize them to fit your project's needs.
</Update>

<Update label="April 26, 2025" tags={["CLI", "Cloud", "Plugins"]}>
  ## Swift maintainability analysis

  Qlty now provides maintainability analysis for Swift. This includes duplication and complexity metrics as well as code smells. The maintainability analysis is available in the Qlty CLI and Qlty Cloud.

  ## ast-grep plugin

  We've added a plugin for [ast-grep](https://ast-grep.github.io/) (sg), a fast polyglot structural search and linting tool supporting 20+ languages. ast-grep offers a pattern language to support writing your own [custom checks](/custom-checks) or adopting checks provided by the ast-grep community.

  ```bash lines theme={"system"}
  qlty plugins enable ast-grep
  ```
</Update>

<Update label="April 25, 2025" tags={["CLI", "Coverage"]}>
  ## Improved coverage uploader output

  We've updated the output from `qlty coverage publish` to include more information to improve the setup an debugging experience.

  ```toml lines theme={"system"}
   SETTINGS

      cwd: /home/runner/work/qlty/qlty
      add-prefix: src/

   METADATA

      CI: GitHub
      Commit: c6dc5239a9e011e55ebdd598e35ce5700dc29741
      Branch: main
      Build ID: 14975425147:1

   COVERAGE FILES: 1

      Coverage File                 Format  Size
      remix/api-coverage/lcov.info  lcov    2.32 KiB

   COVERAGE DATA

      5 unique code file paths
      All code files in the coverage data were found on disk.

      Covered Lines:       57
      Uncovered Lines:     24
      Omitted Lines:      161

      Line Coverage:       70.37%

   EXPORTING...

      Exported: tmp/qlty-coverage/coverage.zip

   AUTHENTICATION

      Auth Method: OIDC
      Token: ***

   PREPARING TO UPLOAD...

      Upload ID: 0efcc860-ede8-4466-9170-038cee46ccd1

   UPLOADING...

      Uploaded 2.34 KiB in 0.28s!
      View report: https://qlty.sh/gh/qltysh/projects/qlty/settings/coverage/uploads/0efcc860-ede8-4466-9170-038cee46ccd1
  ```
</Update>

<Update label="April 17, 2025" tags={["CLI", "Cloud", "Coverage", "Plugins"]}>
  ## Package lockfiles

  The Qlty CLI now uses package lockfiles (e.g. `package-lock.json`, `yarn.lock`, `Gemfile.lock`) when they are available and the `package_file` directive is specified in the `qlty.toml` configuration file. This ensures the exact same linter versions are used across all machines, including Qlty Cloud.

  ## V1 of Coverage GitHub Action

  We've release v1.0.0 of our reusable GitHub Action for coverage uploading. We adhere to [semantic versioning](https://semver.org/) so going forward breaking changes will be represented with a bump in the major version.

  To use the latest version on the v1 line, pin your CI workflows to `@v1` like this:

  ```yaml lines theme={"system"}
  - uses: qltysh/qlty-action/coverage@v1
    with:
        oidc: true
        files: coverage/lcov.info
  ```
</Update>

<Update label="April 15, 2025" tags={["CLI", "Coverage"]}>
  ## BuildKite support

  We now support automatic detection of build metadata from BuildKite. Therefore, uploading code coverage data from BuildKite only requires executing the Qlty CLI with the path to the coverage data file.

  ```shell lines theme={"system"}
  qlty coverage publish coverage.lcov
  ```
</Update>

<Update label="April 11, 2025" tags={["Coverage"]}>
  ## OpenID Connect (OIDC)

  We now support OpenID Connect (OIDC) authentication for code coverage uploads from GitHub Actions.

  OIDC allows us to authenticate the repository running a GitHub Actions workflow with a short-lived token. This enables coverage uploading without needing to manage a long-lived token, providing better security and easier coverage setup.

  ```yaml lines theme={"system"}
  permissions:
    contents: read
    id-token: write # IMPORTANT

  # ... Later in a workflow job: ...
  - uses: qltysh/qlty-action/coverage@v1
    with:
      oidc: true
      files: coverage/lcov.info
  ```
</Update>

<Update label="April 8, 2025" tags={["Plugins"]}>
  ## dockerfmt plugin

  We've add a plugin for [dockerfmt](https://github.com/reteps/dockerfmt), a tool for automatically formatting Dockerfiles.

  ```bash lines theme={"system"}
  qlty plugins enable dockerfmt
  ```
</Update>

<Update label="April 4, 2025" tags={["CLI"]}>
  ## Support Linux Arm64 Musl

  The Qlty CLI now supports Linux systems using Arm64 architecture with Musl. We're now compiling binaries for these target systems with each release.

  To install the Qlty CLI on an Arm64 Linux system using Musl, use our installer:

  ```shell lines theme={"system"}
  curl https://qlty.sh | sh
  ```
</Update>

<Update label="April 3, 2025" tags={["CLI"]}>
  ## SARIF output from Qlty CLI

  The Qlty CLI now supoprts [SARIF](https://sarifweb.azurewebsites.net/) output format. This is a standardized format for static analysis results, making it easier to integrate with other tools and platforms.

  To use the SARIF output format, simply add the `--sarif` flag to your Qlty CLI command. For example:

  ```bash lines theme={"system"}
  qlty check --sarif
  ```
</Update>

<Update label="March 30, 2025" tags={["CLI", "Cloud", "Coverage"]}>
  ## Code coverate tags (beta)

  Qlty Cloud now offers support for Coverage Tags in beta. Coverage Tags are a powerful feature that allow you to group, upload, and report on coverage data with more granularity.

  Coverage Tags are particularly useful to track coverage by suite independently. For example, you can track unit test coverage separately from integration test coverage. They can also be used in monorepos to make it easy to upload and report on coverage by service.

  In addition to providing clear, independent reporting of coverage metrics, Coverage Tags also allow you to carry forward coverage data from previous runs. This means that you can maintain a complete picture of your code coverage over time, even if you only run a subset of all of your tests on each commit.

  To use Coverage Tags, you can add the `--tag` flag to the `qlty coverage publish` command. For example:

  ```bash lines theme={"system"}
  qlty coverage publish --tag unit coverage/unit.lcov
  qlty coverage publish --tag integration coverage/integration.lcov
  ```
</Update>

<Update label="March 27, 2025" tags={["Plugins"]}>
  ## php-cs-fixer plugin plugin

  We've added support for [php-cs-fixer](https://cs.symfony.com/), a tool that fixes your PHP code to follow standards including the PHP coding standards as defined in the PSR-1, PSR-2, etc., or other community driven standards from organizations like Symfony.

  ```bash lines theme={"system"}
  qlty plugins enable php-cs-fixer
  ```
</Update>

<Update label="March 13, 2025" tags={["Plugins"]}>
  ## Checkstyle plugin

  Qlty now supports [Checkstyle](https://checkstyle.sourceforge.io/), a tool that helps programmers write Java code that adheres to a coding standard.

  ```bash lines theme={"system"}
  qlty plugins enable checkstyle
  ```
</Update>

<Update label="March 1, 2025" tags={["Coverage"]}>
  ## Improved coverage comments

  We've made significant improvements to the code coverage summary comments from Qlty Could. The new comments include more information about the coverage impact of your pull request, including diff coverage and a breakdown of coverage changes by file.

  We've also added a "Help" section with definitions for the coverage metrics to help make it easier to interpret the results.
</Update>

<Update label="February 25, 2025" tags={["Cloud", "Coverage"]}>
  ## Support for more SimpleCov formats

  We have added support for additional SimpleCov formats to make it easier to get your code coverage data from SimpleCov ingested into Qlty Cloud. We now support the simplecov-json and simplecov-merged formats.
</Update>

<Update label="February 21, 2025" tags={["CLI"]}>
  ## Negated exclusion patterns

  The Qlty CLI now supports negated exclusion patterns. Exclusion patterns are processed in order, matching the way that Git processes them. This means that if you have a negated pattern that matches a file, it will override any previous exclusion patterns that match the same file.

  You can use negated exclusion patterns in your `qlty.toml` file by prefixing the pattern with an exclamation mark (`!`).

  ```toml lines theme={"system"}
  exclude_patterns = [
    "**/ignores/**.sh",
    "!**/dont_ignore/**",
    "**/ignores/dont_ignore/ignore_this_one.sh"
  ]
  ```
</Update>

<Update label="February 9, 2025" tags={["CLI", "Coverage"]}>
  ## SempahoreCI support

  We now support automatic detection of build metadata from SemaphoreCI. Therefore, uploading code coverage data from SemaphoreCI only requires executing the Qlty CLI with the path to the coverage data file.

  ```shell lines theme={"system"}
  qlty coverage publish coverage.lcov
  ```
</Update>

<Update label="February 7, 2025" tags={["Cloud", "Coverage"]}>
  ## Coverage example repositories

  We now provide code coverage example repositories for many of the programming languages we support. These repositories are designed to help you get started with Qlty Cloud and provide a reference for how to set up code coverage reporting in your own projects.

  You can find links to all of the example repositories in our [documentation](https://docs.qlty.sh/coverage/example-repositories).
</Update>

<Update label="February 1, 2025" tags={["CLI"]}>
  ## Docker images for Qlty CLI

  We now build and publish Docker images for the Qlty CLI. This distribution format is an alternative to our native binaries and enables the use of the Qlty CLI on operating systems that are not natively supported.

  The Docker images are available on [GitHub Container Registry](https://github.com/qltysh/qlty/pkgs/container/qlty).

  ```shell lines theme={"system"}
  docker pull ghcr.io/qltysh/qlty:main
  ```
</Update>

<Update label="January 30, 2025" tags={["Cloud", "Coverage"]}>
  ## Pull request coverage tab

  Qlty Cloud has a new Coverage sub-tab on the Pull Request page. This tab provides a summary of the code coverage for the pull request, including a breakdown of coverage changes by file and their impact on your overall coverage. We also show the diff of the pull request with coverage annotations in the left gutter.
</Update>

<Update label="January 20, 2025" tags={["Cloud", "Coverage"]}>
  ## Workspace-level coverage tokens

  Qlty Cloud now offers Workspace-level coverage tokens in order to simplify the seet up of uploading code coverage data. This feature is particularly useful for organizations that have multiple repositories and want to use the same coverage token across all of them.
</Update>

<Update label="January 16, 2025" tags={["Cloud", "Coverage"]}>
  ## Code coverage debugging information

  We have significantly expanded the amount of debugging information available for code coverage uploads in the Qlty Cloud web app. Navigate the the "Code Covearge" section of Project Settings and you will be able to find a record of every code coverage upload, including the metadata and coverage metrics. We also provide a link to download the coverage information as a Zip file for easy inspeciton if something goes wrong.
</Update>

<Update label="January 15, 2025" tags={["Cloud"]}>
  ## SOC 2 Type II certification

  Qlty Software Inc. is proud to announce that we have achieved SOC 2 Type II certification. You can find our full announcement on our [blog](https://qlty.sh/blog/qlty-achieves-soc-2-type-ii-certification).

  Additional information about our security and compliance program can be found in our [Trust Center](https://trust.qlty.sh/).
</Update>

<Update label="January 7, 2025" tags={["CLI", "Cloud"]}>
  ## C# maintainability analysis

  Qlty now provides maintainability analysis for C#. This includes duplication and complexity metrics as well as code smells. The maintainability analysis is available in the Qlty CLI and Qlty Cloud.
</Update>

<Update label="January 2, 2025" tags={["CLI"]}>
  ## Qlty CLI is now Fair Source

  The Qlty CLI is now released under a Fair Source license. This means that you can use the Qlty CLI for free including in commercial projects, as long as you are not using it to provide a competing service.

  After a delay, the Qlty CLI code reverts to an OSI-approved Open Source license, also known as delayed Open Source publication (DOSP).

  Read the full announcement on our [blog](https://qlty.sh/blog/qlty-cli-is-fair-source).
</Update>