Browse documentation

Guide

Add the check to CI

Run the test check as a CI step and protect its check-only key.

Add a job

Run this in your repository with the released CLI:

cscale init --ci

Init detects your CI host and writes a starting job, or prints commands to add after checkout. It pins the CLI release and verifies its download. It leaves an existing job of the same name alone. The job needs Git 2.39 or newer, the project's tools and dependencies, and Git read access to the target branch. Use full history where your host supports it.

To preview a job for GitLab without writing files:

cscale init --ci --ci-host gitlab --dry-run

The init reference lists host choices. Init needs no sign-in for this step and starts no background check.

Give the job a key

Create a separate check-only key for CI using your personal sign-in. Run cscale key create --name ci --print and pipe its output directly into your CI host's secret store. On macOS, append | pbcopy and paste from the clipboard into the secret store. Name the secret CSCALE_CHECK_KEY and expose it to the check step. Init tells you where to add it for your host. Passkey confirmation applies if enabled. The key is shown only once and does not replace the one saved on your machine.

Never put the key in a command argument, a committed file, or a job log. If delivery fails, list and revoke the lost key before creating another. Set the CI variable CSCALE_WORKSPACE to an organization when checking its workspace; leave it empty for your own workspace.

Run and read the check

The job runs the check as an ordinary CI step:

cscale tests check --ci

The check uses the runner's tools and caches in a private copy. It does not prompt or use a saved account credential. It reads the check-only key from CSCALE_CHECK_KEY. The report names the tested commit, base and target. Settings and path trust come from the target branch.

The report flags edits to CI files and Manual files, including policy, workflow and CODEOWNERS changes. In CI these flags are advisory. Findings appear in the report; the target's policy can make them block. A passing check is complete and has an answered or unneeded model. An incomplete check exits 2 unless a higher-priority failure decides the exit. A check that cannot run, such as one without a secret, exits 1. Your CI host decides whether a failed step blocks a merge. See the test check for the repair loop.

Each CI run registers a check. A fresh runner counts again; a runner that keeps its checkout can replay a registration from the last 23 hours. Machine and CI checks count separately.

Revoke a copied key

Anyone whose branch can run the job may be able to copy its secret. A copied check-only key can run checks as its owner in any workspace they belong to, spending their checks. It can read the owner's usage and acceptance rule, send support requests as them, and withdraw their training consent, deleting kept excerpts. It cannot manage their account or subscription.

Use your personal sign-in to list keys and revoke the affected key immediately:

cscale key list
cscale key revoke 42

Replace 42 with the ID from the list. Create a new CI key and replace the host's secret. The key reference describes revocation.