gitea-admin/CASAN
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: harden CASAN production install lifecycle

Browse Source
This commit is contained in:
thanhnv
2026-07-24 11:11:44 +07:00
parent c7671ab198
commit 114340c719
48 changed files with 1036 additions and 165 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/packaging/CI_GUIDE.md
+16 -22
View File
@@ -11,37 +11,31 @@ cp packages/casan-devkit/templates/gitea-workflow/ci.yml .gitea/workflows/casan-
## 2. What it runs
```yaml
- bash packages/casan-harness/scripts/bash/ci-harness-gate.sh # all governance suites
- bash packages/casan-harness/scripts/bash/verify-audit-chain.sh
- bash packages/casan-harness/scripts/bash/sign-policy-bundle.sh verify
- casan verify-harness
- casan gate
```
## 3. Environment knobs
| Var | Default | Use |
|---|---|---|
| `CASAN_CI_RUN_FRONTEND` | 0 | 1 if you have a frontend workspace |
| `CASAN_CI_RUN_BACKEND` | 0 | 1 to run backend tests |
| `CASAN_CI_RUN_INFRA_LAB` | 0 | 1 to run the Docker infra lab |
| `CASAN_CI_STEP_TIMEOUT_SEC` | 600 | raise to 1200 — some suites are model-backed and run ~450s; 600 flakes under load |
| `CASAN_CI_SUITE_FILTER` | — | regex to run a subset of suites |
| `CASAN_DOMAIN_ROOT` | apps/okr/domain | point at your project's domain |
`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.
## 4. Runner
## 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` (and `node`/`npm` only if you enable apps/okr/frontend/backend tests).
`bash`, `python3`, `openssl`, the approved global CASAN release, and the toolchain
declared by the project manifest.
## 5. Expected result
`CI_GATE_SUMMARY PASS=<n> FAIL=0 SKIP=<k>`. Any FAIL fails the job (exit 1). The gate is
## 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.
## 6. This repo's own CI
The source hub's active pipeline is `.gitea/workflows/ci.yml` (frontend tests → security
gate → deploy). It already runs the gate from the promoted root layout
(`packages/casan-harness/...`). Use it as a worked example.
## 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 gate green as an invariant; every new control must ship a fail-able adversarial test.
- 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: `bin/casan gate` (or a filtered subset).
- For a quick local pre-push check: `casan gate`.