Git Integration

TestMesh integrates with Git providers to run tests automatically when code changes. Connect your repositories to trigger flows on push, pull request, or specific commit events. AI-powered diff analysis identifies which tests are most relevant, and results are posted directly back to your pull requests as comments and commit status checks.

Connecting a Provider

Configure a Git integration in the dashboard under Settings → Integrations or via the API:

curl -X POST http://localhost:5016/api/v1/workspaces/$WORKSPACE_ID/integrations \
  -H "Content-Type: application/json" \
  -d '{
    "type": "github",
    "name": "My GitHub",
    "config": {
      "webhook_secret": "your-webhook-secret",
      "token": "ghp_your_personal_access_token"
    }
  }'

Supported Providers

Webhook Setup

After creating the integration, TestMesh provides a webhook URL to register with your Git provider:

https://your-testmesh.example.com/api/v1/webhooks/github

Set this as the webhook URL in your repository or organization settings. Use the same webhook_secret value in both TestMesh and your Git provider.

Repository Links

Link flows to specific Git repositories to enable change-aware test selection:

curl -X POST http://localhost:5016/api/v1/workspaces/$WORKSPACE_ID/repository-links \
  -H "Content-Type: application/json" \
  -d '{
    "flow_id": "flow-uuid",
    "repository": "owner/my-repo",
    "service_paths": ["src/user-service/", "src/auth/"],
    "integration_id": "integration-uuid"
  }'

service_paths tells TestMesh which directories in the repository are relevant to this flow. When a commit touches files in these paths, this flow is a candidate for triggering.

Trigger Rules

Trigger rules define exactly which flows to run for which Git events.

Create a Trigger Rule

curl -X POST http://localhost:5016/api/v1/workspaces/$WORKSPACE_ID/git-trigger-rules \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Run on PR to main",
    "integration_id": "integration-uuid",
    "repository": "owner/my-repo",
    "event_types": ["pull_request"],
    "branches": ["main"],
    "flow_ids": ["flow-uuid-1", "flow-uuid-2"],
    "environment_id": "staging-env-uuid",
    "enabled": true
  }'

Rule Configuration

Examples

Run integration tests on every push to main:

{
  "name": "Main branch integration tests",
  "event_types": ["push"],
  "branches": ["main"],
  "flow_ids": ["integration-suite-flow"]
}

Run smoke tests on pull requests to any release branch:

{
  "name": "Release branch smoke tests",
  "event_types": ["pull_request"],
  "branches": ["release/*"],
  "flow_ids": ["smoke-test-flow"]
}

Run all tests when a tag is created:

{
  "name": "Tag: full test suite",
  "event_types": ["create"],
  "branches": ["v*"],
  "flow_ids": ["smoke-flow", "integration-flow", "e2e-flow"]
}

Webhook Delivery

TestMesh logs every webhook delivery with its payload and processing result. Access delivery history:

# List recent webhook deliveries
curl http://localhost:5016/api/v1/workspaces/$WORKSPACE_ID/webhooks/deliveries

# Get a specific delivery
curl http://localhost:5016/api/v1/webhooks/deliveries/$DELIVERY_ID

Each delivery record includes:

• Received timestamp
• Event type and repository
• Processing status (queued, processed, failed)
• Which trigger rules matched
• Which flows were triggered

Diff Analysis

When a webhook arrives, TestMesh can use AI to analyze the diff and determine which flows are most relevant to the change — even for flows not explicitly in a trigger rule.

Enable diff analysis in the integration settings:

{
  "type": "github",
  "config": {
    "diff_analysis": true,
    "ai_provider": "anthropic"
  }
}

When enabled, TestMesh:

1. Fetches the diff from the Git provider API
2. Analyzes which services and code paths changed
3. Matches changes to flows linked to those paths via repository links
4. Adds those flows to the triggered run queue

This is useful for monorepos where a single push may touch multiple services.

Self-Healing

Self-healing automatically attempts to fix test flows that break after a code change. When a triggered run fails, TestMesh can:

1. Fetch the diff that caused the failure
2. Analyze the failure alongside the code change using AI
3. Generate a patch to update the flow
4. Create a pull request or apply the fix directly

Configure self-healing per integration:

{
  "type": "github",
  "config": {
    "self_healing": {
      "enabled": true,
      "mode": "pr",      // "pr" creates a PR, "auto" applies directly
      "target_branch": "main"
    }
  }
}

PR Write-Back

When a pull request is opened or updated, TestMesh can analyze the change and post results directly to the PR. This includes:

1. Commit status checks — show pending / success / failure on the PR
2. Analysis comments — post a detailed markdown comment with findings
3. Fix suggestions — include actionable suggestions in the comment

How It Works

PR opened / synchronized
    ↓
Set commit status → "pending"
    ↓
Fetch diff from GitHub API
    ↓
Index code changes (embeddings, if configured)
    ↓
Run diff analysis (impact + coverage agents)
    ↓
Format findings as markdown comment
    ↓
Post comment to PR
    ↓
Set commit status → "success" / "failure"

Configure PR Write-Back

Enable PR write-back in the integration's pr config:

curl -X PATCH http://localhost:5016/api/v1/admin/integrations/$INTEGRATION_ID \
  -H "Content-Type: application/json" \
  -d '{
    "config": {
      "pr": {
        "comment_on_pr": true,
        "set_commit_status": true
      }
    }
  }'

PR Comment Format

The comment includes:

• Summary of affected flows and coverage
• Per-finding severity (critical / warning / info)
• Suggested fixes with confidence scores
• Links to affected flows in the TestMesh dashboard

Auto-Fix PRs

When self-healing generates a high-confidence suggestion, TestMesh can automatically create a fix PR that applies the suggested YAML changes.

How It Works

1. Self-healing analyzes a test failure triggered by the PR
2. If the suggestion confidence exceeds auto_pr_threshold, TestMesh:
   • Creates a branch: testmesh/fix/{suggestion-id}
   • Pushes the updated YAML flow file(s)
   • Opens a PR targeting the original branch
   • Posts a comment on the original PR linking to the fix PR

Enable Auto-Fix PRs

{
  "config": {
    "pr": {
      "comment_on_pr": true,
      "set_commit_status": true,
      "auto_pr_enabled": true,
      "auto_pr_threshold": 0.85
    }
  }
}

With auto_pr_threshold: 0.85, only suggestions with 85%+ confidence will trigger an automatic fix PR. Lower-confidence suggestions are still included in the PR comment for manual review.

Status Checks

When running flows triggered by a pull request, TestMesh reports the result back to the Git provider as a commit status check. This lets you enforce passing tests as a merge requirement.

The status check shows:

• pending — analysis is in progress
• success — analysis completed, no critical findings
• failure — critical findings or errors detected

Status checks are enabled via the pr.set_commit_status config field (see PR Write-Back above).

The status context is testmesh/analysis and includes a description summarizing the findings count.

What's Next