CI/CD Integration for API Testing
Run Keploy API tests in any CI/CD pipeline — Woodpecker, GitLab CI, Jenkins, CircleCI, Drone. Gate pull requests on deterministic replay results, cache captured artifacts between runs, and alert to Slack or Discord when tests fail. No SDK, no proxy, no application code changes — Keploy captures at the kernel level with eBPF.
This guide covers the exact pipeline files for each major CI system, the pattern for gating pull requests on test results, and how to integrate failure alerts into your team chat.
Woodpecker pipeline
Drop this file into .woodpecker.yml at the repo root. It runs on every pull request and on pushes to main, installs Keploy via the one-line installer, builds the application, replays the committed keploy/ test fixtures, and uploads the test report to S3 via the Woodpecker S3 plugin. Keploy's own infrastructure runs on Woodpecker — this config is the one we use internally.
# .woodpecker.yml
# Install, build, and replay run in a single step because each
# Woodpecker step launches its own container and binaries do not
# persist across steps.
when:
- event: pull_request
- event: push
branch: main
steps:
keploy-replay:
image: ubuntu:22.04
commands:
- apt-get update && apt-get install -y curl golang-go
- curl -fsSL https://keploy.io/install.sh | bash
- go build -o ./app ./cmd/server
- keploy test -c "./app" --delay 10
upload-report:
image: woodpeckerci/plugin-s3
settings:
bucket: keploy-ci-reports
source: keploy/reports/
target: /${CI_REPO}/${CI_COMMIT_SHA}/
when:
status: [success, failure]
To gate PRs on the Keploy step, mark keploy-replay as a required status check in the Woodpecker admin UI or equivalent repository host protection rule. Non-zero exit codes from keploy test will now block merges.
GitLab CI pipeline
The GitLab equivalent uses the same phases (install → build → test → report) but hooks into GitLab's native JUnit report ingestion so test results appear directly in the MR widget.
# .gitlab-ci.yml
keploy-tests:
stage: test
image: ubuntu:22.04
before_script:
- apt-get update && apt-get install -y curl golang-go
- curl -fsSL https://keploy.io/install.sh | bash
- go build -o ./app ./cmd/server
script:
- keploy test -c "./app" --delay 10
artifacts:
when: always
paths:
- keploy/reports/
reports:
junit: keploy/reports/junit.xml
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
To gate merge requests, enable "Pipelines must succeed" in Settings → Merge requests. Keploy's JUnit output is rendered in the MR widget under the "Test summary" tab so reviewers see individual failing assertions without leaving GitLab.
Jenkins declarative pipeline
The Jenkins pattern uses a declarative pipeline with a Slack notification step in the failure post-hook. Requires the Slack Notification plugin configured with a workspace-level webhook.
// Jenkinsfile
pipeline {
agent { label 'linux' }
stages {
stage('Install Keploy') {
steps {
sh 'curl -fsSL https://keploy.io/install.sh | bash'
}
}
stage('Build') {
steps {
sh 'go build -o ./app ./cmd/server'
}
}
stage('Keploy Tests') {
steps {
sh 'keploy test -c "./app" --delay 10'
}
}
}
post {
always {
archiveArtifacts artifacts: 'keploy/reports/**/*', allowEmptyArchive: true
junit 'keploy/reports/junit.xml'
}
failure {
slackSend channel: '#qa-alerts',
color: 'danger',
message: "Keploy tests failed on ${env.BRANCH_NAME} — ${env.BUILD_URL}"
}
}
}
CircleCI, Drone, GitHub Actions
The same three-phase pattern (install → build → test) maps directly onto CircleCI orbs, Drone pipelines, and GitHub Actions workflows. Full example configs for each are in the Keploy docs at /docs/ci-cd. The only substantive difference is how each system exposes caching — CircleCI uses the save_cache / restore_cache commands, Drone uses plugin volumes, and GitHub Actions uses actions/cache.
Caching captured test artifacts
Keploy test fixtures live in the keploy/ directory committed to git, so they are always available from the checkout. What benefits from caching is the install step and any pre-built language runtimes. The cache key should include three signals so cached artifacts are invalidated on any relevant change:
- Keploy version (hash of
install.shor pinned binary SHA) - Application dependency lockfile (
go.sum,package-lock.json,requirements.txt,Cargo.lock) - keploy.yaml content (so configuration changes invalidate any cached noise rules)
Alerting to Slack and Discord
The Keploy test runner emits a structured JSON summary after each run. Pipe it to a Slack webhook via a post-step hook (or the Jenkins slackSend step shown above) so failed PRs trigger a channel alert. Discord uses the same pattern with a Discord webhook URL. Both integrations are configured via repository secrets and can be scoped to specific branches — the most common setup is to only alert on main or on explicitly labeled PRs to avoid channel noise from in-progress drafts.
Frequently asked questions
Join our GlobalCommunity
Connect with developers worldwide. Follow updates, ask questions, share feedback, and ship faster with other Keploy builders.
