The command line in CI

CI has no browser, so it uses a token instead of qaldy login.

Make a token#

From your terminal, once:

qaldy tokens create --name "GitHub Actions" --read-only --days 90

The command asks you to approve in the browser (a token can never make another token), prints the token once and saves nothing. Put it in the job's secrets as QALDY_TOKEN. Prefer --read-only and a short life. Revoke it on the Agents page in the console at any time.

A GitHub Actions job#

name: Qaldy health
on:
  schedule: [{ cron: "0 6 * * 1-5" }]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - name: Fail if any app is failing
        env:
          QALDY_TOKEN: ${{ secrets.QALDY_TOKEN }}
        run: |
          npx --yes --package=https://app.qaldy.com/cli/qaldy-cli.tgz qaldy apps --status failing --json \
            | node -e 'const d=JSON.parse(require("fs").readFileSync(0)); if (d.apps.length) { console.error(d.apps.map(a=>a.name).join(", ")); process.exit(1) }'

What to rely on#

• Exit codes are part of the contract: 0 done, 1 failed, 2 usage, 3 not signed in or token refused, 4 planned. See the full list.
• --json prints one JSON document on standard output and nothing else. Progress goes to standard error.
• CI=true (which most CI sets) makes the audit log record the call as ci/… and keeps the CLI from opening a browser.
• qaldy apps run <app> --wait exits 1 if the run fails, so a deploy job can gate on it.

What CI cannot do#

A token acts as the person who approved it, in one workspace, and is refused on anything that spends money, changes who has access or widens an app's reach. A CI job cannot approve a build that sends messages, reaches the internet, uses AI or starts shared; it gets approval_needs_console and a link. That is by design, and it is why a leaked CI token is a bounded problem.