CKB for DevOps: Automate Code Intelligence in Your Pipeline
By CKB Team
CKB started as a tool for AI coding assistants, but its code intelligence is just as valuable in CI/CD pipelines. This guide shows DevOps and platform engineers how to automate code analysis, reduce CI time, and catch risky changes before they merge.
What CKB Brings to CI/CD
- Blast radius analysis — Know exactly what breaks before merging
- Smart test selection — Run only tests affected by changes (89% CI time reduction)
- Risk scoring — Quantified risk based on hotspots, complexity, and history
- Suggested reviewers — Based on actual code ownership, not guesswork
- Complexity gates — Block merges that exceed thresholds
- Dead code detection — Identify unused code automatically
- Coupling analysis — Warn when tightly-coupled files change independently
Quick Start
Add CKB to any CI pipeline in 3 steps:
# 1. Install
npm install -g @tastehub/ckb
# 2. Index
ckb init && ckb index
# 3. Analyze
ckb pr-summary --base=main --head=HEAD
GitHub Actions Integration
Here's a minimal workflow that adds CKB analysis to PRs:
# .github/workflows/ckb-analysis.yml
name: CKB Analysis
on:
pull_request:
branches: [main]
jobs:
analyze:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # Required for git-blame analysis
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Cache CKB Index
uses: actions/cache@v4
with:
path: .ckb/
key: ckb-${{ runner.os }}-${{ github.sha }}
restore-keys: ckb-${{ runner.os }}-
- name: Install and Index
run: |
npm install -g @tastehub/ckb
ckb init
ckb index
- name: Analyze PR
run: ckb pr-summary --base=main --format=markdown >> $GITHUB_STEP_SUMMARY
GitLab CI Integration
# .gitlab-ci.yml
ckb-analysis:
image: node:20
stage: test
before_script:
- npm install -g @tastehub/ckb
- ckb init && ckb index
script:
- ckb pr-summary --base=$CI_MERGE_REQUEST_TARGET_BRANCH_NAME --format=markdown
cache:
key: ckb-index
paths:
- .ckb/
only:
- merge_requests
Smart Test Selection
This is where CKB pays for itself. Instead of running your entire test suite on every PR, run only the tests affected by the changes:
- name: Get Affected Tests
id: tests
run: |
TESTS=$(ckb affected-tests --range=origin/main..HEAD --output=command)
echo "tests=$TESTS" >> $GITHUB_OUTPUT
- name: Run Affected Tests
run: ${{ steps.tests.outputs.tests }}
Real savings:
| Scenario | Full Suite | Affected Tests | Savings |
|---|---|---|---|
| 10,000 tests, 45 min | 45 min | ~5 min | 89% |
| 50 CI runs/day | 37.5 hours | ~4 hours | $500+/day |
CKB maps your git diff to symbols, then uses the call graph to identify which tests exercise that code.
Risk Scoring
CKB calculates risk based on 8 factors:
| Factor | Weight | Description |
|---|---|---|
| Complexity | 20% | Cyclomatic/cognitive complexity |
| Test coverage | 20% | Percentage of code covered |
| Bus factor | 15% | Number of contributors |
| Security sensitive | 15% | Contains auth/crypto code |
| Staleness | 10% | Time since last modification |
| Error rate | 10% | Runtime errors from telemetry |
| Coupling | 5% | Tightly coupled files |
| Churn | 5% | Frequency of changes |
Use risk scores to flag PRs that need extra review:
- name: Check Risk Level
run: |
RISK=$(ckb pr-summary --base=main --format=json | jq -r '.riskAssessment.level')
if [ "$RISK" = "high" ]; then
echo "::warning::High-risk PR - extra review recommended"
fi
Complexity Gates
Block merges when code complexity exceeds thresholds:
- name: Complexity Gate
run: |
MAX_COMPLEXITY=$(ckb complexity --changed --format=json | jq '.summary.maxCyclomatic')
if [ "$MAX_COMPLEXITY" -gt 15 ]; then
echo "::error::Cyclomatic complexity $MAX_COMPLEXITY exceeds limit (15)"
exit 1
fi
HTTP API for Automation
For advanced integrations, CKB provides an HTTP API:
# Start the server
ckb serve --port 8080 &
# Query PR summary
curl -X POST http://localhost:8080/pr/summary \
-H "Content-Type: application/json" \
-d '{"baseBranch": "main", "headBranch": "HEAD"}'
Key endpoints:
| Endpoint | Method | Description |
|---|---|---|
/pr/summary |
POST | PR analysis with ownership |
/hotspots |
GET | High-churn files |
/telemetry/dead-code |
GET | Dead code candidates |
/complexity |
GET | File complexity analysis |
/health |
GET | Liveness probe |
/ready |
GET | Readiness probe |
/metrics |
GET | Prometheus metrics |
Prometheus Metrics
CKB exports metrics for your observability stack:
curl -s http://localhost:8080/metrics
| Metric | Type | Description |
|---|---|---|
ckb_requests_total |
Counter | Total API requests |
ckb_request_duration_seconds |
Histogram | Request latency |
ckb_cache_hits_total |
Counter | Cache hit count |
ckb_symbols_indexed |
Gauge | Number of indexed symbols |
ckb_index_age_seconds |
Gauge | Time since last index |
Incremental Indexing
CKB supports incremental indexing that only processes changed files:
| Scenario | Full Index | Incremental |
|---|---|---|
| Large project (10k files) | ~60s | ~2-5s |
| Typical PR (5-10 files) | ~60s | ~1-2s |
| Single file hotfix | ~60s | <1s |
Key insight: PR pipelines typically change a small fraction of files. Incremental indexing is O(changed files), not O(total files).
- name: Cache Index
uses: actions/cache@v4
with:
path: .ckb/
key: ckb-${{ runner.os }}-${{ github.ref }}-${{ github.sha }}
restore-keys: |
ckb-${{ runner.os }}-${{ github.ref }}-
ckb-${{ runner.os }}-
- name: Index (Incremental)
run: ckb init && ckb index # Incremental by default
Use ckb index --force for nightly builds when maximum accuracy matters.
Kubernetes Deployment
If running CKB as a service:
# kubernetes deployment
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 2
CLI Commands Reference
# PR analysis
ckb pr-summary --base=main --head=HEAD --format=markdown
# Impact analysis
ckb impact diff --base=main --format=json
# Affected tests
ckb affected-tests --range=main..HEAD --output=command
# Suggested reviewers
ckb reviewers --range=main..HEAD --format=gh
# Complexity analysis
ckb complexity internal/query/engine.go --format=json
# Coupling analysis
ckb coupling --files=file1.go,file2.go --min-correlation=0.7
# Risk audit
ckb audit --min-score=60 --limit=20
# Dead code detection
ckb dead-code --threshold=0.9 --limit=20
# Hotspots
ckb hotspots --limit=20
Recommended Rollout
- Start with PR comments (informational only)
- Add hotspot warnings after you trust the data
- Enable smart test selection for immediate CI time savings
- Add complexity gates with generous thresholds initially
- Enable blocking only after the team trusts the signals
Full Workflow Example
Here's a production-ready workflow combining multiple CKB features:
name: CKB Full Analysis
on:
pull_request:
branches: [main]
jobs:
analyze:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-node@v4
with:
node-version: '20'
- uses: actions/cache@v4
with:
path: .ckb/
key: ckb-${{ runner.os }}-${{ github.sha }}
restore-keys: ckb-${{ runner.os }}-
- name: Setup CKB
run: |
npm install -g @tastehub/ckb
ckb init && ckb index
- name: PR Summary
run: ckb pr-summary --base=main --format=markdown >> $GITHUB_STEP_SUMMARY
- name: Complexity Check
run: |
ckb complexity --changed --format=json > complexity.json
MAX=$(jq '.summary.maxCyclomatic' complexity.json)
if [ "$MAX" -gt 20 ]; then
echo "::warning::High complexity detected ($MAX)"
fi
- name: Get Affected Tests
id: tests
run: |
TESTS=$(ckb affected-tests --range=origin/main..HEAD --output=command)
echo "tests=$TESTS" >> $GITHUB_OUTPUT
- name: Run Affected Tests
if: steps.tests.outputs.tests != ''
run: ${{ steps.tests.outputs.tests }}
What's Next
- CI/CD Feature Page — Detailed documentation
- Quality Gates — Configure complexity and risk thresholds
- GitHub Examples — Ready-to-use workflow files
CKB turns code intelligence from a manual process into automated infrastructure. Your pipelines become smarter, your tests run faster, and risky changes get caught before they merge.
Links:
- Get Started
- All Features
- Pricing - Free for personal use