Continuous measurement in your pipeline

How it works

A diagnosis run inside the product is a photograph: the state of a repository at one moment. The CI check turns it into a film. On every build the CLI sends the checked-out repository to ScaleQuality, the engine re-measures it, and the result lands on that repository's timeline in the product.

The same step is also a gate. Give it a code-maturity cutoff and it exits non-zero below that number, which fails the job. Leave the cutoff off and it measures on every build without ever blocking a merge. Only a measurement fails the job: when ScaleQuality cannot measure a build, the step says it was not measured and exits 0.

A project can be one folder of a monorepo. The check asks ScaleQuality which folders the upload measures (the module in --project and the modules the change touched) and reads the durability of each folder on its own, from the same history, as ScaleQuality reads a module. A check before 0.5.8 sends only the whole repository's, and the module shows durability as not measured.

Before you start

Set it up

Four steps, around ten minutes. Steps 1 and 4 happen inside ScaleQuality, steps 2 and 3 inside your CI.

# .github/workflows/scalequality.yml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0   # full history: durability is measured with git blame
- run: npx @scalequality/check@0.5.8 --token "$SQ_TOKEN" --project <projectId> --host https://app.scalequality.io
  env:
    SQ_TOKEN: ${{ secrets.SQ_TOKEN }}

Measured test coverage

Nothing computes coverage by looking at a repository, and no tool does: coverage only exists once the tests actually run and the runner writes a report. What ScaleQuality does is import that report. What is different is that you do not have to tell us where it is.

Run your tests with coverage before the check step and the verdict shows line coverage, labelled MEASURED, naming the report it came from. Without a report the verdict answers a narrower question, and says which one.

Produce the report

Add coverage to the test command you already run in this job. Each of these writes to a path the check finds on its own.

scalequality.properties

Optional, at the repository root, in the same shape as sonar-project.properties so nobody has to learn a second dialect. Unknown keys are ignored, so a file written for a newer engine never breaks an older one.

# Optional. Only needed when the defaults do not fit.

# Where your coverage report lands, if it is not in the usual place.
sq.coverage.reportPaths=target/site/jacoco/jacoco-aggregate.xml

# Files that are not application modules, so they stop counting as untested.
sq.exclusions=src/main/java/**/generated/**,**/*.pb.go

# Test roots and class suffixes your house uses that nobody else does.
sq.test.inclusions=qa
sq.test.suffixes=Should,Fixture

CLI reference

The check is published on npm as @scalequality/check. The snippets pin a version on purpose: a gate that can break a build must not change engine between two runs of the same commit.

npx @scalequality/check@0.5.8 --help

Options

Exit codes

Only a measurement fails the build. A problem on our side, an expired token or a lapsed plan never turns your build red unless you pass --strict, and such a build never reads as passed: the step leaves a warning on the run and in the job summary saying it was not measured, and why.

Troubleshooting

The failures below are the ones that show up in real pipelines, roughly in the order they tend to happen.