F6.2 — CI/CD Pipeline

What it does

• CI (.github/workflows/ci.yml) runs on every pull request and every push to main: lint, typecheck, test and build as four separate jobs, so a failure points straight at the cause.
• Release (.github/workflows/release.yml) runs when a tag matching v* is pushed: it re-runs CI, creates a GitHub release with generated notes, and builds and pushes the Docker images to GHCR.
• Changelog is generated from Conventional Commits by git-cliff, configured in cliff.toml.

How it works

Each CI job installs with pnpm install --frozen-lockfile (Node 22, pnpm version from packageManager), then runs the matching root script (pnpm lint, pnpm typecheck, pnpm test, pnpm build), which Turborepo maps to the workspaces. Typecheck, test and build run prisma generate first with a placeholder DATABASE_URL (generation never connects), the same trick as system/scripts/install/steps/09-build.sh. @vexlyx/shared is built by Turborepo's ^build dependency. The API tests are mocked unit tests and need no Postgres or Redis; the Python suites under tests/ need live Docker services and are not run in CI.

Release images, published to ghcr.io/atlantiqshq/:

Image	Dockerfile	Notes
vexlyx-dashboard	apps/dashboard/Dockerfile	Self-contained Next.js standalone image. NEXT_PUBLIC_* values are baked in at build time, so the published image uses the defaults.
vexlyx-api	apps/api/Dockerfile	Runtime toolchain only (Node, Python, Docker CLI, Nixpacks). By design it ships no app code; the installer bind-mounts the host build.

Tags: X.Y.Z, plus X.Y and latest for stable tags. A tag containing - (for example v1.0.0-rc.1) is a prerelease: it gets a prerelease GitHub release and no latest tag.

Cutting a release

git tag v0.1.0
git push origin v0.1.0

Keep commit messages in type(scope): summary form so they land in the right changelog section. To refresh the committed CHANGELOG.md, run git cliff -o CHANGELOG.md locally after tagging and commit it.

Branch protection

Once CI is stable, require the lint, typecheck, test and build checks on main in the repository settings (and Docs / build for docs changes).

How to test

Open a pull request and check that all four jobs pass. To test a release, push a prerelease tag such as v0.0.1-rc.1, confirm the release and both images appear, then delete the tag, release and package versions.

How to extend

• Dashboard tests use Vitest (apps/dashboard/vitest.config.ts, src/**/*.test.ts).
• Staging auto-deploy on merge is not implemented; add a job to release.yml or a new workflow when a staging server exists.