CI/CD Pipeline for Kaneo: GitHub Actions, pnpm, and Monorepo Testing Explained

Kaneo uses a GitHub Actions workflow defined in .github/workflows/ci.yml to run five sequential jobs—lint, typecheck, unit, build, and integration—on Ubuntu 24.04 runners using pnpm and Node.js 20, followed by automated Docker and Helm chart releases.

The CI/CD pipeline for Kaneo orchestrates quality checks and deployments for this open-source project management platform. According to the usekaneo/kaneo source code, the entire automation stack relies on GitHub Actions workflows that enforce code quality across a pnpm-powered monorepo before shipping containerized artifacts.

Overview of the CI Workflow

The primary continuous integration configuration lives in .github/workflows/ci.yml. This workflow triggers on every push, pull request, or manual dispatch, spinning up separate jobs that execute in parallel on fresh Ubuntu 24.04 environments. Each job follows an identical setup sequence before running its specific validation step, ensuring consistent tooling versions across all stages.

Common Setup Pattern

Every CI job executes these four steps before running commands:

1. Checkout the repository using actions/checkout@v7.
2. Set up pnpm (v10.32.1) via pnpm/action-setup@v6.
3. Set up Node.js 20.20.2 with actions/setup-node@v7 and pnpm caching enabled.
4. Install dependencies using a frozen lockfile: pnpm install --frozen-lockfile.

The Five CI Jobs Explained

Lint Job

The lint job enforces code style and catches syntax errors using Biome. After the standard setup, it executes:

pnpm exec biome ci .

This command, referenced at line 33 of the workflow file, scans the entire monorepo for formatting and linting violations without applying fixes, ensuring that only compliant code reaches the main branch.

Typecheck Job

The typecheck job runs the TypeScript compiler across all packages to detect type errors before runtime. Following the same environment setup, it invokes:

pnpm typecheck

As implemented at line 56, this step validates type safety for the API, Web frontend, and documentation packages simultaneously.

Unit Job

The unit job executes fast, isolated tests using Vitest. It runs:

pnpm test

See line 79 of .github/workflows/ci.yml. This provides immediate feedback on business logic correctness without requiring external services.

Build Job

The build job compiles production bundles for every package in the workspace, verifying that the entire monorepo can be bundled successfully. It executes:

pnpm build

Referenced at line 102, this step catches build-time errors in the API, Web, and Docs applications that might not appear during development.

Integration Job

The integration job runs tests requiring external dependencies like PostgreSQL. It executes:

pnpm test:integration

As defined at line 146, this job validates real-world database interactions and service integrations that unit tests cannot cover.

Release Automation

After CI jobs succeed, two additional workflows handle deployment artifacts.

Docker Image Pipeline

The .github/workflows/docker.yml workflow builds and pushes container images for the API and Web applications to the GitHub Container Registry. Upon successful image publication, it triggers the Helm chart workflow to ensure new versions are immediately available for deployment.

Helm Chart Pipeline

The .github/workflows/helm-chart.yml workflow lints, templates, packages, and publishes the Kaneo Helm chart. This allows Kubernetes clusters to pull the latest application versions using standardized infrastructure-as-code practices.

Running CI Steps Locally

You can replicate the CI environment locally using these commands:

# Install exact dependencies (same as CI)

pnpm install --frozen-lockfile

# Lint the whole monorepo

pnpm exec biome ci .

# Type-check the TypeScript sources

pnpm typecheck

# Run all unit tests

pnpm test

# Build production bundles for API, Web, and Docs

pnpm build

# Run integration tests (requires a local PostgreSQL instance)

pnpm test:integration

Key Configuration Files

• .github/workflows/ci.yml — Defines the five core CI jobs (lint, typecheck, unit, build, integration).
• .github/workflows/docker.yml — Builds and publishes Docker images for API and Web components.
• .github/workflows/helm-chart.yml — Packages and releases the Helm chart for Kubernetes deployments.
• package.json (root) — Configures pnpm workspace scripts referenced by CI commands.
• pnpm-workspace.yaml — Lists monorepo packages, ensuring CI runs across all components.

Summary

• Kaneo’s CI/CD pipeline uses GitHub Actions with workflows defined in .github/workflows/ci.yml.
• Five distinct jobs—lint, typecheck, unit, build, and integration—run on Ubuntu 24.04 using pnpm v10.32.1 and Node.js 20.20.2.
• Biome handles linting, while Vitest powers unit tests and custom scripts manage integration testing.
• Successful CI triggers automated Docker image builds and Helm chart publications via separate workflows.
• All steps can be reproduced locally using pnpm commands with the frozen lockfile flag.

Frequently Asked Questions

What triggers the CI/CD pipeline in Kaneo?

The pipeline triggers on every push to any branch, every pull request targeting the main branch, or manual workflow dispatches through the GitHub Actions interface. This ensures that all proposed changes pass the full validation suite before merging.

Which Node.js version does Kaneo use in CI?

Kaneo pins Node.js 20.20.2 across all CI jobs, as specified in the setup-node action configuration. This consistency prevents version-related build failures and ensures reproducible environments between local development and CI runners.

How does Kaneo handle monorepo testing?

The CI leverages pnpm workspaces configured in pnpm-workspace.yaml to run commands across all packages simultaneously. The unit and integration jobs execute pnpm test and pnpm test:integration from the root, which cascade through the API, Web, and Docs packages according to the workspace topology.

What happens after CI jobs pass?

Upon successful completion of all five CI jobs, the Docker workflow automatically builds container images for the API and Web applications and pushes them to the registry. This subsequently triggers the Helm chart workflow, which packages and publishes the updated chart for Kubernetes deployments.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}