Automate reproduction workflow with GitHub Agentic Workflows (gh-aw)

[sl0thentr0py]

Summary

Automate the existing repro skill so that it runs automatically via GitHub Agentic Workflows (gh-aw) whenever a new issue is labeled Bug on any Sentry SDK repository.

Motivation

Today the repro skill is invoked manually via Claude Code. Automating it means every bug report gets a reproduction attempt without human intervention, speeding up triage and making it easier for SDK maintainers to verify and fix bugs.

Plan

Phase 1: gh-aw workflow on getsentry/repro

Create .github/workflows/auto-repro.md — a gh-aw workflow that:

• Trigger: workflow_dispatch with an issue_url input (the full GitHub issue URL)
• Engine: Claude (engine: { id: claude })
• Tools: github, bash, edit, web-fetch
• Runtimes: Node, Python, Ruby (to build & test reproductions across SDK languages)
• Instructions (markdown body): Port the logic from the existing repro SKILL.md — parse the issue URL, fetch issue details, create a minimal reproduction directory, test it, commit, and open a PR
• Safe-outputs:
  • create-pull-request — open the reproduction PR on this repo
  • add-comment — comment back on the original SDK issue with a link to the PR (using target-repo)
• Guardrails:
  • rate-limit to cap runs (e.g. max 10 per hour)
  • concurrency with job-discriminator: ${{ inputs.issue_url }} to avoid duplicate runs for the same issue
  • timeout-minutes: 30

After writing the .md file, run gh aw compile to generate the .lock.yml and commit both.

Phase 2: Cross-repo trigger from SDK repositories

Create a reusable standard GitHub Actions workflow in this repo (e.g. .github/workflows/trigger-repro.yml) that SDK repos can call. It:

1. Triggers on issues event with types: [labeled]
2. Filters: only proceeds if the added label is Bug
3. Fires workflow_dispatch on getsentry/repro → auto-repro with the issue URL as input
4. Requires a shared secret (REPRO_DISPATCH_TOKEN) — a GitHub App token or PAT with actions:write on getsentry/repro

Each SDK repo then adds a thin caller workflow:

# .github/workflows/repro-on-bug.yml
name: Trigger reproduction
on:
 issues:
 types: [labeled]
jobs:
 dispatch:
 if: github.event.label.name == 'Bug'
 uses: getsentry/repro/.github/workflows/trigger-repro.yml@main
 secrets:
 REPRO_DISPATCH_TOKEN: ${{ secrets.REPRO_DISPATCH_TOKEN }}

Phase 3: Roll out to SDK repos

Add the caller workflow to each SDK repository:

• getsentry/sentry-python
• getsentry/sentry-javascript
• getsentry/sentry-ruby
• getsentry/sentry-rust
• getsentry/sentry-java
• getsentry/sentry-dotnet
• getsentry/sentry-php
• getsentry/sentry-go
• (others as needed)

Set up the REPRO_DISPATCH_TOKEN org-level secret (or per-repo).

Phase 4: Guardrails & polish

• Deduplication: Before creating a reproduction, check if an open PR already exists for that issue (title match Reproduction for {repo}#{number})
• Skip criteria: Skip issues that are already closed, or that have a label like needs-more-info
• Notifications: Post a "reproduction in progress" comment on the issue when the workflow starts, so reporters know it's being worked on
• Monitoring: Use gh-aw's observability/OTLP support to track success rates and failure modes

Open questions

• GitHub App vs PAT for cross-repo dispatch — a GitHub App scoped to the org is cleaner long-term
• Should we gate on additional labels (e.g. skip wontfix, duplicate)?
• Max concurrency across all SDK repos — what's a reasonable limit?
• Should failed reproduction attempts still open a (draft) PR, or just comment on the issue?