Skip to main content
Integrate Basecut into your CI/CD workflow to automatically seed test databases, refresh dev snapshots, or validate schema migrations with production-like data.

GitHub Actions

Test with Production-Like Data

Restore a snapshot before running your test suite:
Secrets to configure (Settings → Secrets):
  • BASECUT_API_KEY: Your Basecut API key
  • AWS_ACCESS_KEY_ID: AWS credentials (if snapshot stored in S3)
  • AWS_SECRET_ACCESS_KEY: AWS secret key

Create Snapshot on Schedule

Refresh your dev snapshot weekly with latest production data:

Test Schema Migrations

Validate migrations against production-like data before deploying:

GitLab CI

Test Pipeline with Snapshot Restore

CI/CD Variables (Settings → CI/CD → Variables):
  • BASECUT_API_KEY: Your Basecut API key (masked)
  • AWS_ACCESS_KEY_ID: AWS credentials (masked)
  • AWS_SECRET_ACCESS_KEY: AWS secret key (masked, protected)

Scheduled Snapshot Creation

Setup: Go to CI/CD → Schedules → Create new schedule (e.g., weekly on Mondays).

CircleCI

Test Job with Snapshot

Environment Variables (Project Settings → Environment Variables):
  • BASECUT_API_KEY
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

Jenkins

Declarative Pipeline

Credentials: Add basecut-api-key in Jenkins → Manage Credentials.

Docker Compose for CI

For local CI testing or custom CI systems:
Run locally:

Best Practices

1. Use Dedicated Test Snapshots

Create separate snapshots for CI with:
  • Stable sampling: Use sampling.seed when sampling.mode: random
  • Small size: Faster restore (use limits.rows.per_table)
  • Stable schema: Update when schema changes, not on every run

2. Cache Basecut CLI Installation

GitHub Actions:
GitLab CI:

3. Handle Restore Failures Gracefully

4. Parallel Test Jobs

Restore snapshot once, run tests in parallel:

5. Use Read-Only Database Credentials

Never commit credentials to source control. Use your CI platform’s secret management to store BASECUT_API_KEY and database credentials. See Agent Deployment for the recommended read-only user setup.

Troubleshooting

Snapshot Restore Too Slow

  • Use smaller snapshot: Reduce limits.rows.per_table
  • Cache restore: Restore once, reuse DB dump (see parallel tests above)
  • Local storage: Use local filesystem for CI snapshots (faster than S3)

Authentication Failures

Database Connection Refused

  • Ensure services container is healthy before restoring
  • Check depends_on with condition: service_healthy
  • Increase --health-interval if database starts slowly

Next Steps

Common Workflows

Other patterns for development, debugging, and data sharing

Agent Deployment

Run your own agents for private databases

Environment Variables

Complete CLI configuration reference

Troubleshooting

Debug common CI/CD issues