Files
CASAN/docs/packaging/CI_GUIDE.md
T

42 lines
1.5 KiB
Markdown

# 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:
```bash
cp packages/casan-devkit/templates/gitea-workflow/ci.yml .gitea/workflows/casan-ci.yml
```
## 2. What it runs
```yaml
- 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`.