Issue Tracking (Jira & GitHub)
Auto-file GitHub Issues or Jira tickets per failure cluster. Updates and de-duplicates across runs. Auto-resolves when failures clear.
Issue Tracking
AegisRunner can auto-create tickets in GitHub Issues or Jira whenever a test fails, so failures are tracked in the same place as the rest of your engineering work. This guide walks through both integrations and the per-failure controls.
Available integrations
| Provider | What gets created |
|---|---|
| GitHub Issues | An issue per failure cluster, labeled aegisrunner. Includes failure details, screenshots, and a link to the run. |
| Jira | A ticket per failure cluster, in the configured project + issue type. Includes the same context. |
Tickets are per cluster, not per individual test. If 12 cart tests fail with the same root cause, you get one ticket — not twelve. The ticket is updated if the same cluster recurs.
How it works
- A test run finishes with failures.
- Failure triage clusters them.
- For each cluster above a configurable severity threshold, a ticket is created (or updated if it already exists).
- Tickets are linked from the run page; failures are linked from the ticket.
- Tickets stay open until you close them manually — AegisRunner doesn't auto-close based on subsequent passes.
Setting up GitHub Issues
- Open Project → Integrations → Issue Tracking.
- Click Connect GitHub. You'll be redirected to GitHub to authorize the AegisRunner app.
- Pick the repository to file issues into.
- Optionally configure:
- Default labels — applied to every issue (e.g.
bug,regression,aegisrunner). - Default assignee — usually your on-call or QA lead.
- Severity threshold — only cluster severity ≥ X creates a ticket. Defaults to
medium.
- Default labels — applied to every issue (e.g.
- Save.
Required GitHub App permissions: issues: write, metadata: read. AegisRunner only sees the repo you select.
Setting up Jira
- Open Project → Integrations → Issue Tracking.
- Click Connect Jira.
- Enter your Jira site URL (e.g.
https://acme.atlassian.net). - Authenticate with an API token. Generate one at id.atlassian.com.
- Pick the project and issue type (Bug, Task, Story).
- Configure default fields:
- Default assignee.
- Default priority.
- Default labels.
- Severity threshold.
- Save.
What goes in each ticket
Every auto-created ticket includes:
- Title — cluster name ("Cart page elements not found").
- Severity / priority — mapped from the triage cluster severity.
- Root cause — one sentence from triage.
- Recommended fix — one paragraph from triage.
- Affected tests — list with links into AegisRunner.
- Failure samples — first 3 failures with error messages and screenshot links.
- Run link — direct URL to the AegisRunner run.
- Browser, environment, commit SHA — context.
Updates and de-duplication
If the same cluster appears in a subsequent run:
- The existing ticket gets a comment with the new run's details ("Reproduced in run X").
- The "last seen" timestamp is updated.
Tickets stay open until closed manually. If you want a "this is fixed" signal, close the ticket from your tracker — AegisRunner doesn't second-guess your team's resolution decisions.
Per-test overrides
Some tests are intentionally allowed to fail (negative tests, environment health checks). To exclude a specific test from auto-ticketing:
- Open the test in the suite.
- Tag it with
no-issue-tracking.
Failed tests with that tag are excluded from cluster ticketing.
Plan availability
| Plan | GitHub Issues | Jira |
|---|---|---|
| Free | — | — |
| Starter | — | — |
| Pro | ✓ | ✓ |
| Business | ✓ | ✓ |
| Enterprise | ✓ | ✓ (with custom field mappings) |
Common questions
Can I file to multiple repos / projects?
One target per integration. If you need to route different test suites to different repos, configure separate AegisRunner projects.
Can I customize the ticket template?
Title and body templates are configurable on Business+ — set them under integration settings using {{cluster_name}}, {{root_cause}}, {{run_url}} etc. as variables.
How do I disconnect?
Click Disconnect under integration settings. Existing tickets stay in your tracker; future failures stop creating new ones.
Related
- Failure Triage — how clusters are formed.
- Notifications & Alerts — Slack/email on the same failures.
- CI/CD Integration — PR comments alongside tickets.