Skip to main content
Components group the files in a project by path, so you can see coverage for each service, package, or team inside one repository. You define components in Qlty Cloud, not in CI, so you can add or change them at any time without touching your coverage uploads. Qlty already aggregates coverage by directory in the Code view, so when each service lives in its own top-level directory you can see its coverage there without any setup. Components are for groupings that do not follow the directory tree: a team that owns several services spread across a monorepo, a shared library plus the places that use it, or all the files matched by one entry in a CODEOWNERS file.

​
Components or coverage tags?

Both features break coverage down into smaller pieces, but they work differently: Start with components. They need no CI changes, and you can adjust them as your codebase changes. Use coverage tags when your CI runs test suites selectively, for example a monorepo that only runs the tests for the service that changed. In that setup, Qlty needs tags to carry forward coverage for the suites that did not run. Tags and components can be used together.

​
Enabling components

Components are enabled per project. You need admin access to the project.
  1. Open the project and go to Project Settings > Features.
  2. Under Analytics, turn on Components.
Once enabled, a Components tab appears in the project navigation.

​
Defining a component

  1. Go to Project Settings > Components.
  2. Click Create Component.
  3. Fill in the component details and save.
The components list in Project Settings > Components shows a Files count for each component: the number of files on the default branch that its patterns match. Use it to confirm that your patterns select the files you expect. From the same list you can edit, duplicate, or delete a component.

​
Path patterns

Each pattern is matched against a file’s path relative to the root of the repository, for example backend/api/users.py. These are the same paths that appear in your coverage reports after path fixing. A file belongs to a component when it matches at least one of the component’s patterns. The rules are:
  • A pattern must match the whole path. backend on its own matches nothing inside the backend/ directory. Use backend/*.
  • A star matches any characters, including slashes. * is not limited to one directory level: backend/* matches every file under backend/ at any depth, and backend/*.py matches both backend/app.py and backend/api/users.py.
  • A double star behaves the same as a single star. backend/** and backend/* select the same files.
  • Every other character is literal. ?, [abc], {a,b}, and ! have no special meaning. To cover several directories, add one pattern for each.
backend/**/*.py requires at least one directory between backend/ and the file, so it skips files directly inside backend/. To select every Python file under backend/, use backend/*.py.
Components do not have to cover the whole repository, and they can overlap:
  • A file that matches no component is left out of every component. It still counts toward the project’s total coverage.
  • A file that matches several components counts toward each of them.

​
Example: components by owning team

A monorepo where each team owns a few services and packages, in directories that are not grouped by team: Each team’s component rolls up coverage across everything it owns, which no single directory in the Code view would show.

​
Where component coverage appears

​
Components tab

The project’s Components tab lists every component with its metrics on the default branch: files, lines of code, maintainability, complexity, duplication, coverage, and issues. Click a component to see its files with per-file coverage.

​
Pull request coverage

On a pull request’s Coverage tab, the Components sub-view lists each component that contains a file changed by the pull request. For each one it shows the coverage rating on the base and the head, the coverage percentage on the head, and the change between the two. This view compares against the pull request’s base, so it needs a coverage report for the base commit. It is empty when the pull request changes no files that belong to a component.

​
Pull request comments

The coverage summary comment includes a Modified Components table. It lists the same components as the pull request’s Components sub-view, with each component’s coverage rating and its diff coverage: the coverage of the lines the pull request changed in that component.

​
REST API

The API returns the latest metrics and the metric history for a component, including coverage.

​
Changing a component

When you edit a component’s path patterns, the Components tab and pull request views use the new definition right away. Metric history is different. Qlty records each component’s coverage when a coverage report is processed, using the component’s definition at that time. Editing a component does not recalculate the history that was already recorded. Selective coverage uploads do not contribute to component coverage.

​
Managing components with the API

Components can also be managed through the REST API. Teams use it to keep components in sync with a CODEOWNERS file, so each owner’s component tracks the paths the file assigns to them: In the API, pathGlobs is an array with one pattern per entry. Components must be enabled for the project before they can be created or changed through the API.

​
See Also