---

Title: Repository Setup. Description: Configure migration paths and analysis rules for your repositories.

REPOSITORY SETUP

Configure how CAPYSQUASH analyzes migrations in each repository.

LINKING PROJECTS TO REPOSITORIES

Each CAPYSQUASH project can be linked to a GitHub repository:

LINK A PROJECT

GO TO PROJECT SETTINGS

Dashboard → Projects → [Your Project] → Settings → GitHub

1. SELECT REPOSITORY
Choose from your installed repositories dropdown
1. CONFIGURE PATHS
Specify where your migrations live
1. SET RULES
Define analysis behavior and thresholds

MIGRATION PATH CONFIGURATION

Tell CAPYSQUASH where to find your migration files:

Common Patterns

📁 SUPABASE

Supabase/migrations

🔷 PRISMA prisma/migrations/

🐘 STANDARD migrations/

CUSTOM

Db/migrate

Multiple Paths

If your migrations are in multiple directories:

Migrations

Database/migrations

Sql

Solution: Add all paths (comma-separated):

migrations/, database/migrations/, sql/

File Pattern

Specify which files are migrations:

Pattern	Example Files
`*.sql` (default)	`001_init.sql`, `002_users.sql`
`*.up.sql`	`001_init.up.sql`
`*_migration.sql`	`20240101_migration.sql`
Custom regex	Advanced patterns

Example custom pattern:

^\d{14}_.*\.sql$

Matches: 20240101120000_add_users.sql

BRANCH CONFIGURATION

Control which branches trigger analysis:

Option 1: All Branches (Default)

Analyze PRs targeting any branch:

branches: '*'

Best for: Most projects

Option 2: Specific Branches

Only analyze PRs to specific branches:

branches:
  - main
  - develop
  - production

Best for: Projects with strict branch workflow

Option 3: Branch Patterns

Use glob patterns:

branches:
  - main
  - release/*
  - hotfix/*

Best for: Gitflow or release branch strategies

ANALYSIS RULES

Configure when and how analysis runs:

Trigger Events

☑ AUTO-ANALYZE WHEN

► PR opened ► PR updated (new commits) ► PR reopened ► Manual comment trigger

⏭️ SKIP ANALYSIS WHEN
► No migration files changed
► PR marked as draft (optional)
► PR from bot (optional)
► Specific labels present

Skip Labels

Prevent analysis when PR has certain labels:

skip_labels:
  - skip-analysis
  - wip
  - do-not-merge

Add these labels to PRs to bypass CAPYSQUASH analysis.

Safety Level Override

Override project default safety level for PR analysis:

pr_safety_level: conservative # Options: paranoid, conservative, standard, aggressive

Use case: Be more conservative for PR analysis than local development.

STATUS CHECK CONFIGURATION

Control how CAPYSQUASH reports pass/fail:

Check Behavior

CHECK MODES

☑

INFORMATIONAL
Always pass, show results only
Best for: Teams starting with CAPYSQUASH
⚠️
WARNING
Pass with warnings, highlight issues
Best for: Balanced approach
☒
BLOCKING
Fail on issues, block merge
Best for: Strict migration quality

Failure Conditions

Define what causes a check to fail (only in BLOCKING mode):

fail_conditions:
  data_loss_risk: true # Fail if data loss detected

  warning_threshold: 3 # Fail if more than 3 warnings

  consolidation_threshold: 70 # Fail if >70% can be consolidated

  deployment_time_minutes: 10 # Fail if estimated deployment >10 min

Example scenarios:

Condition	Triggers Failure
Data loss risk	☑ Always fail (recommended)
5 warnings, threshold 3	☑ Fails
50% consolidation, threshold 70%	☑ Passes
12 min deployment, threshold 10 min	☑ Fails

MONOREPO CONFIGURATION

For repositories with multiple projects:

Path-Based Detection (Simple)

Link different projects to different paths:

Project: API
Repository: monorepo
Path: services/api/migrations/
Project: Dashboard
Repository: monorepo
Path: services/dashboard/migrations/
Project: Mobile
Repository: monorepo
Path: services/mobile/migrations/

CAPYSQUASH detects which project to analyze based on changed files.

Config File (Advanced)

Create .CAPYSQUASH.yml in repository root:

version: 1

projects:
  - name: 'API'
    path: 'services/api/migrations'
    label: 'api'
    safety: conservative

  - name: 'Dashboard'
    path: 'services/dashboard/migrations'
    label: 'dashboard'
    safety: standard

  - name: 'Mobile'
    path: 'services/mobile/migrations'
    label: 'mobile'
    safety: aggressive

Benefits:

Version controlled configuration
Label-based project routing
Per-project safety levels
Team can modify without dashboard access

Label-based routing: Add labels to PRs to explicitly route to a project:

PR with api label → Analyzes API project
PR with dashboard label → Analyzes Dashboard project

NOTIFICATION CONFIGURATION

Get notified about analysis results:

PR Comments (Always On)

CAPYSQUASH always posts results as PR comment.

Additional Notifications

notifications:
  email:
    enabled: true
    recipients:
      - team@company.com
    events:
      - analysis_failed
      - warnings_detected

  slack:
    enabled: true
    webhook_url: 'https://hooks.slack.com/...'
    channel: '#migrations'
    events:
      - analysis_completed
      - data_loss_risk

  discord:
    enabled: true
    webhook_url: 'https://discord.com/api/webhooks/...'

Configure organization-wide notifications →

CUSTOM COMMENT TEMPLATE

Customize the PR comment format (Professional/Enterprise):

comment_template: |
  ## 🦫 Migration Analysis

  **Impact:** {{file_count}} files → {{optimized_count}} files ({{reduction}}%)
  **Warnings:** {{warnings_count}}

  {{#has_warnings}}
  ### ⚠️ Warnings

  {{#warnings}}
  - {{message}}
  {{/warnings}}
  {{/has_warnings}}

  {{#recommendations}}
  ### <span className="inline-flex items-center gap-2"><Lightbulb size={24} weight="bold" /> Recommendations</span>

  {{#items}}
  - {{text}}
  {{/items}}
  {{/recommendations}}

  [View full analysis →]({{analysis_url}})

Available variables:

` - Number of migration files
` - Files after consolidation
` - Percentage reduction
` - Number of warnings
` - Link to full results
Plus: warnings array, recommendations array, etc.

EXAMPLE CONFIGURATIONS

Startup - Aggressive Development

branch: main
path: supabase/migrations/
safety_level: standard
check_mode: informational
skip_draft_prs: true

Why: Fast iteration, don't block PRs, improve over time

Enterprise - Strict Quality

branches:
  - main
  - production
path: migrations/
safety_level: conservative
check_mode: blocking
fail_conditions:
  data_loss_risk: true
  warning_threshold: 0
  deployment_time_minutes: 5
skip_draft_prs: true
skip_bot_prs: true

Why: Production stability, zero-tolerance for risks

Agency - Multi-Client


# Each client project configured separately

# Client A

branches: ["main", "staging"]
path: migrations/
check_mode: warning
safety_level: conservative

# Client B

branches: ["production"]
path: db/migrate/
check_mode: blocking
safety_level: paranoid

Why: Different clients, different requirements

TESTING CONFIGURATION

After setup, test your configuration:

1. Create Test PR

git checkout -b test-config
echo "CREATE TABLE test (id INT);" > your-migration-path/test.sql
git add .
git commit -m "test: configuration"
git push origin test-config