CASAN CI Guide (Gitea Actions)

Wire the CASAN governance gate into your project's CI so every push/PR is governed.

1. Add the workflow

DevKit install.sh already drops .gitea/workflows/casan-ci.yml. To add manually, copy the template:

cp packages/casan-devkit/templates/gitea-workflow/ci.yml .gitea/workflows/casan-ci.yml

2. What it runs

- casan verify-harness
- casan gate

CASAN_PROJECT_MANIFEST must point to the project's manifest. Build and test commands come from that reviewed manifest; the production package does not contain CASAN's own source-hub test suites.

3. Runner

Uses runs-on: ci-runner (a self-hosted Gitea Actions runner). To set one up on your host, see .gitea/vps-setup-runbook.md and scripts/setup-ci-runner.sh. The runner needs bash, python3, openssl, the approved global CASAN release, and the toolchain declared by the project manifest.

4. Expected result

PROJECT_GATE_SUMMARY ... FAIL=0. Any FAIL fails the job (exit 1). The gate is fail-closed: missing signatures/policy in enforced mode (CASAN_PROFILE=prod or CASAN_VERIFY_STRICT=1) also fail.

5. This repo's own CI

The source hub's active pipeline still runs internal regression and adversarial suites. Those suites validate CASAN itself and are intentionally excluded from customer/runtime artifacts.

Tips

Keep the project gate green as an invariant.
Do not stage runtime log artifacts (.specify/logs, evidence) produced by gate runs.
For a quick local pre-push check: casan gate.

1.5 KiB Raw Blame History