Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/arrozet/caret/llms.txt

Use this file to discover all available pages before exploring further.

Caret’s CI/CD strategy combines GitHub Actions for automated quality gates with Coolify’s branch-watching auto-deploy for frictionless production releases. Every change that reaches the prod branch should have passed linting, type checking, unit tests, integration tests, and a successful Docker build — Coolify then picks up the commit and redeploys the production stack automatically without any manual intervention. The pipeline is designed around two branches: main for integration work and prod for production promotion.
GitHub Actions workflow files have not yet been checked into .github/workflows. The pipeline design documented on this page is the intended architecture, but the actual YAML workflow files still need to be created. Adding these workflow files is a tracked next step. The Coolify auto-deploy side is operational — it redeploys on every push to prod.

Branch Strategy

BranchPurpose
mainPrimary integration branch — day-to-day feature and fix work lands here
prodProduction branch — Coolify watches this branch and redeploys on every push
Changes flow from feature branches → main (via pull request and review) → prod (via a promotion merge or direct push when ready for release).

Pipeline Stages

The full intended pipeline runs four sequential stages. Each stage must pass before the next begins.
1
Lint and type check
2
Runs static analysis and type checking across every service in the monorepo.
3
Node.js services (frontend, api-gateway, auth-service, document-service, collab-service):
4
  • ESLint for style and logic errors
  • TypeScript compiler (tsc --noEmit) for type safety
  • Managed with Bun — never npm, yarn, or pnpm
  • 5
    # Example for a Node service (via Makefile)
    make api-gateway-lint
    make document-service-lint
    make frontend-lint
    
    6
    Python AI service:
    7
  • Ruff for linting and formatting checks
  • Pyright for static type analysis
  • Managed with uv
  • 8
    make ai-service-lint
    
    9
    All lint targets are available as make <service>-lint and their auto-fix variants as make <service>-lint-fix.
    10
    Tests
    11
    Tests run in order from fastest to slowest: unit → integration → E2E.
    12
    Unit tests — fast, isolated, no external dependencies:
    13
    make frontend-test-unit
    make api-gateway-test-unit
    make auth-service-test-unit
    make document-service-test-unit
    make collab-service-test-unit
    make ai-service-test-unit
    
    14
    Integration tests — exercise service boundaries and database interactions (require Supabase credentials):
    15
    make frontend-test-integration
    make api-gateway-test-integration
    make auth-service-test-integration
    make document-service-test-integration
    make collab-service-test-integration
    make ai-service-test-integration
    
    16
    End-to-end tests (optional / gated): Playwright browser tests that exercise the full user journey through the running stack. E2E tests are optional in the pipeline and can be skipped for hotfix deployments.
    17
    Build Docker images and validate the production compose file
    18
    Builds every service image to verify the Dockerfiles are correct and confirms the production compose file is syntactically valid and all required environment variables are declared:
    19
    # Validate the production compose file
    docker compose -f docker-compose.prod.yml config
    
    # Build all production images
    docker compose -f docker-compose.prod.yml build
    
    20
    A failed build in CI blocks the deploy step and prevents a broken image from reaching production.
    21
    Deploy via Coolify
    22
    Coolify monitors the prod branch for new commits. On every push, it automatically:
    23
  • Pulls the latest code from GitHub.
  • Rebuilds Docker images using docker-compose.prod.yml.
  • Performs a rolling restart of all services.
  • Reports deployment status back to the Coolify dashboard.
  • 24
    No manual trigger is needed for a standard deployment. The GitHub Actions workflow should push to (or promote) prod only after all previous stages pass.

    Secrets Management

    Secrets are split into two categories depending on where they are consumed.

    GitHub Actions Secrets

    Values that are only needed during CI — for example credentials used to build Docker images, publish artefacts, or trigger Coolify webhooks. Store these in Settings → Secrets and variables → Actions on the GitHub repository.

    Coolify Environment Variables

    Runtime secrets consumed by containers at startup — database URLs, API keys, JWT secrets. Store these in the Coolify project’s environment variable editor so they are injected at deploy time and never persist in the repository.
    Never commit secrets to the repository. This applies to .env files, hardcoded credentials in source code, and any workflow YAML that echoes secret values. Rotate any secret that has been accidentally committed immediately. Use .gitignore to exclude .env from version control and audit pull requests for leaked credentials.

    Tooling Reference

    ServicePackage ManagerLinterType CheckerTest Runner
    frontendBunESLinttscVitest
    api-gatewayBunESLinttscVitest
    auth-serviceBunESLinttscVitest
    document-serviceBunESLinttscVitest
    collab-serviceBunESLinttscVitest
    ai-serviceuvRuffPyrightPytest
    Package manager discipline is strict: use Bun for all Node.js services and uv for the Python AI service. Never use npm, yarn, pnpm, pip, poetry, or pipenv — even in CI workflow files.

    Emergency Deployments

    While CI workflow files are still being set up, you can trigger a production deployment at any time using the Manual Redeploy button in the Coolify dashboard. Navigate to your project, select the affected service or the whole compose resource, and click Redeploy. This is the recommended approach for emergency rollouts or hotfixes until the full GitHub Actions pipeline is in place.

    Next Steps

    The following workflow files need to be created under .github/workflows/ to complete the CI/CD pipeline:

    lint.yml

    Run ESLint + tsc across all Node services and Ruff + Pyright for the AI service on every pull request targeting main.

    build.yml

    Build all Docker images and validate docker-compose.prod.yml on every push to main and prod.

    test-unit.yml

    Run unit tests for all six services in parallel on every pull request.

    test-integration.yml

    Run integration tests against a live Supabase test project on merges to main.

    deploy.yml

    Trigger a Coolify webhook (or push to prod) after all other jobs pass to initiate the production deploy.

    e2e.yml

    Optional Playwright end-to-end suite gated on the prod branch to validate critical user journeys after deploy.

    Build docs developers (and LLMs) love