Kaneo CI/CD Pipelines Explained: GitHub Actions, Docker & Helm Workflows

Kaneo uses GitHub Actions as its CI/CD platform with three workflow files—ci.yml, docker.yml, and helm-chart.yml—that automate linting, type checking, testing, building, containerization, and Kubernetes deployment packaging on every push, pull request, or manual trigger.

Kaneo's continuous integration and continuous deployment setup is orchestrated entirely through GitHub Actions. The usekaneo/kaneo repository defines its automation in .github/workflows/, leveraging a pnpm-based monorepo structure with Node.js 20.20.2 and Ubuntu 24.04 runners. This article breaks down each pipeline job, its purpose, and how the workflows interconnect to deliver production-ready artifacts.

Core CI Workflow: .github/workflows/ci.yml

The primary CI pipeline lives in .github/workflows/ci.yml and executes five parallel jobs on every trigger. Each job follows a standardized setup pattern before running its specific validation step.

Job 1: Lint (Biome)

Purpose: Enforce code style and catch syntax errors early.

# From .github/workflows/ci.yml - line 33

- name: Run Biome lint
  run: pnpm exec biome ci .

The lint job uses Biome—a fast, Rust-based toolchain—to validate formatting and catch lint errors across the entire codebase. This runs before any compilation or testing to provide immediate feedback on code quality issues.

Job 2: Typecheck (TypeScript)

Purpose: Verify type safety across all monorepo packages.

# From .github/workflows/ci.yml - line 56

- name: Run typecheck
  run: pnpm typecheck

Running the TypeScript compiler in noEmit mode ensures type consistency without generating output files. This catches interface mismatches and generic errors that unit tests might miss.

Job 3: Unit Tests (Vitest)

Purpose: Execute fast, isolated tests for individual modules.

# From .github/workflows/ci.yml - line 79

- name: Run unit tests
  run: pnpm test

The unit test job spins up Vitest across all workspace packages. These tests avoid external dependencies like databases, providing rapid feedback on business logic correctness.

Job 4: Build

Purpose: Verify that production bundles compile successfully.

# From .github/workflows/ci.yml - line 102

- name: Run build
  run: pnpm build

This compiles the API, Web frontend, and documentation sites into deployable artifacts. A failing build step prevents broken deployments from reaching the release pipeline.

Job 5: Integration Tests

Purpose: Validate end-to-end behavior with real database connections.

# From .github/workflows/ci.yml - line 146

- name: Run integration tests
  run: pnpm test:integration

Unlike unit tests, this job requires a PostgreSQL service container. It exercises database queries, migrations, and API endpoints in conditions that mirror production.

Release Workflow: .github/workflows/docker.yml

After CI passes, the Docker pipeline handles containerization. Located at .github/workflows/docker.yml, this workflow:

1. Builds multi-platform Docker images for the API and Web services.
2. Pushes images to the GitHub Container Registry with semantic version tags.
3. Triggers the Helm chart workflow via repository dispatch.

The API and Web apps each have independent Dockerfile definitions in their respective package directories, enabling optimized layer caching and minimal final image sizes.

Deployment Workflow: .github/workflows/helm-chart.yml

The final stage of Kaneo's CI/CD pipeline packages Kubernetes manifests. The .github/workflows/helm-chart.yml workflow:

• Lints Helm templates with helm lint
• Renders manifests with helm template for validation
• Packages the chart into a .tgz archive
• Publishes to GitHub Container Registry as an OCI artifact

This workflow can trigger manually or receive dispatches from the Docker pipeline, ensuring charts stay synchronized with application images.

Shared Setup Pattern Across All Jobs

Every CI job in ci.yml uses identical initialization steps. This consistency reduces maintenance burden and ensures reproducible environments:

steps:
  - uses: actions/checkout@v7
  
  - name: Setup pnpm
    uses: pnpm/action-setup@v6
    with:
      version: 10.32.1
  
  - name: Setup Node
    uses: actions/setup-node@v7
    with:
      node-version: 20.20.2
      cache: 'pnpm'
  
  - name: Install dependencies
    run: pnpm install --frozen-lockfile

The --frozen-lockfile flag guarantees that CI uses exact dependency versions recorded in pnpm-lock.yaml, eliminating "works on my machine" discrepancies.

Local Development Commands Matching CI

Run the same validation steps locally before pushing:

# 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 local PostgreSQL)

pnpm test:integration

Monorepo Configuration Files

The CI/CD pipeline relies on two root-level configuration files to understand workspace structure:

File	Purpose
package.json	Defines workspace scripts (test, build, typecheck) invoked by CI
pnpm-workspace.yaml	Lists packages to include in the monorepo (API, Web, Docs, etc.)

Changes to either file can affect how CI distributes work across the codebase.

Workflow Triggers and Concurrency

The ci.yml workflow responds to:

• Push events to main and feature branches
• Pull request opens and updates
• Manual dispatch via GitHub's Actions UI

Kaneo uses concurrency controls to cancel stale runs when new commits arrive, preventing resource waste on outdated code versions.

Summary

• .github/workflows/ci.yml defines five validation jobs: lint (Biome), typecheck (TypeScript), unit tests (Vitest), build, and integration tests (PostgreSQL-backed).
• .github/workflows/docker.yml builds and publishes container images, then triggers Helm chart updates.
• .github/workflows/helm-chart.yml packages and publishes Kubernetes deployment artifacts to GitHub Container Registry.
• All jobs use pnpm 10.32.1 and Node.js 20.20.2 on Ubuntu 24.04 with locked dependency installation.
• The pipelines enforce code quality, type safety, test coverage, build integrity, and deployment readiness before any release artifacts are generated.

Frequently Asked Questions

What triggers the Kaneo CI/CD pipelines?

Pushes to any branch, pull request activity, and manual workflow dispatches all trigger the CI pipeline in .github/workflows/ci.yml. The Docker and Helm workflows trigger conditionally—either after successful CI completion or through manual invocation and inter-workflow dispatches.

Does Kaneo use self-hosted runners for CI/CD?

No. According to the source code in .github/workflows/ci.yml, all jobs specify runs-on: ubuntu-24.04, which uses GitHub's hosted runners. There are no self-hosted runner configurations present in the repository.

How does Kaneo handle database dependencies in tests?

The integration test job configures a PostgreSQL service container directly in the workflow file. This provides an isolated database instance that starts automatically before tests run and terminates afterward, ensuring clean state without external infrastructure dependencies.

Can I run the full CI pipeline locally?

Partially. You can execute pnpm install --frozen-lockfile, pnpm exec biome ci ., pnpm typecheck, pnpm test, and pnpm build locally using the same commands as CI. However, pnpm test:integration requires a running PostgreSQL instance that you must provision manually, as GitHub Actions' service container syntax has no local equivalent.

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