CI and testing

CI’s job is to ruin your afternoon before users do. Beskid splits that work across your repo and the compiler superproject.

In your repository

Typical pipeline:

1. Install pinned or rolling CLI (Downloads).
2. beskid fetch / lockfile discipline per workspace guide.
3. beskid test with --include-tag fast on every push; slow or integration on nightly or main.
4. Optional: beskid analyze / beskid build on the same graph so tests do not run against fantasy projects.

Use --json when a bot needs to summarize failures without reading ANSI colors.

In the compiler repository

GitHub Actions on compiler/ runs Rust tests that embed or drive Beskid fixtures—not a substitute for your app tests, but the authority on whether E1601 still means what the spec says.

Workspace members tied to verification (from compiler/Cargo.toml):

• beskid_analysis, beskid_codegen, beskid_engine, beskid_aot — pipeline under test
• beskid_tests, beskid_e2e_tests — conformance anchors
• beskid_cli — command surface parity

Superrepo and website CI

The aggregate repo may run bun run verify:trudoc on docs and platform-spec gates separately from your package tests. Docs green + app red is still a bad release—just a different failure mode.

Reference links

• Testing framework
• Conformance area
• Build / analyze / run contract

Next chapter

09. Contracts, effects, and other polite threats