CI/CD Pipeline

Updated: Wed 06 May 2026 17:14:18 CEST — Phase 1 naming migration: removed Lovable Preview / pnpm references; restructured per service

Each Plings service has its own CI pipeline because each is its own repository. Vercel handles the build-and-deploy step for all of them; GitHub Actions handles lint, type-check, and test.

graph TD; PR[Pull Request] --> CI[GitHub Actions: lint + type-check + test]; CI -->|push| VercelPreview[Vercel preview deployment]; Main[Merge to main] --> VercelProd[Vercel production deployment];

Plings-Web

GitHub Actions on PR:

  1. Install — npm install (or bun install — both lockfiles currently exist; pick one consistently)
  2. Lint — npm run lint
  3. Type-check — tsc --noEmit
  4. Build — npm run build (Vite)
  5. Tests — (not yet wired; Vitest + React Testing Library is the planned setup)

Preview deployment: Vercel auto-deploys every push to a non-main branch. Production deployment: triggered by merge to main.

Plings-Gateway

Similar shape: lint, build, deploy. The Gateway runs on Vercel Edge so the build output is bundled differently and bundle size matters more.

Plings-API

GitHub Actions on PR:

  1. Install — pip install -r requirements.txt
  2. Type-check — mypy (configured in pyproject.toml)
  3. Tests — pytest once the test suite is systematized; today the repo has many test scripts in the root that aren’t yet a formal pytest suite
  4. Deploy — Vercel triggered by merge to main

Reminder: Vercel deploys Plings-API from requirements.txt. Always update it before merging if dependencies change. See Deployment Procedures.

Failure handling

A failing CI step blocks merge. Vercel preview-build failures are posted to the PR conversation by the Vercel GitHub integration.

Release tagging

There is no formal release-tag scheme today. If/when needed, tag vX.Y.Z on main after a successful production deploy.