ci-defect-filer

An action-taking orchestrator for SDETs and DevOps engineers. Takes one CI failure artifact and produces one filed (or commented) tracker issue - no manual triaging step required between pipeline and tracker.

When invoked

Required inputs:

• Path to a failure artifact: JUnit XML, Allure JSON result file, pytest --tb=short log, or Playwright report.json.
• Tracker platform: jira | linear | github.
• Auth env vars: JIRA_BASE + JIRA_EMAIL + JIRA_TOKEN for Jira (HTTP Basic per developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/ (opens in new window)); LINEAR_KEY for Linear (no Bearer prefix for personal API keys, per linear.app/developers/graphql (opens in new window)); GITHUB_TOKEN + GITHUB_REPO for GitHub (per docs.github.com/en/rest/issues/issues (opens in new window)).
• For Jira: JIRA_PROJECT_KEY. For Linear: LINEAR_TEAM_ID.

Optional: LOOKBACK_DAYS (dedupe window; default 90).

The agent refuses if no failure artifact is supplied - it will not synthesize a bug report from a description alone. Requires a real structured failure record.

Step 1 - Parse and build the bug spec

Invoke the from-CI-failure workflow in the preloaded bug-report-template skill (qa-bug-repro).

It ingests the artifact (auto-detected by extension), extracts test name, assertion message, stack trace, CI environment variables, and linked artifacts (screenshots, video, HAR). It proposes severity from the assertion class (AssertionError - Medium; TimeoutError / ConnectionError - High; per the skill's SEVERITY_FROM_ERROR table) and defect type per IEEE 1044. Output is a tracker-agnostic bug_spec YAML object.

Use jq to validate the emitted spec has non-empty title and body before proceeding:

echo "$BUG_SPEC" | jq -e '.title | length > 0' > /dev/null

If the artifact contains multiple failures, produce one spec per failure and process each independently through Steps 2-4.

Step 2 - Detect the tracker and verify auth

Use Bash(jq *) to read tracker config from env. Check that the required env vars are set; if any are missing, halt and list them.

Auto-detect the tracker from the supplied platform arg rather than sniffing the URL - the same Jira tenant can host both bug and non-bug projects.

Step 3 - Deduplicate

Search the tracker with four strategies, in order, using the platform helpers in the preloaded bug-tracker-workflow skill; combine scores and keep the top candidate.

3a - Exact-title substring search (score 1.0 exact / 0.6 partial overlap):

• Jira: POST /rest/api/3/search/jql with text ~ "{title}" AND issuetype = Bug AND statusCategory != Done (the search_jql helper).
• Linear: issues query with title: { contains: title_text } and state: { type: { neq: "completed" } } filter (the find_dupes helper in the Linear reference).
• GitHub: GET /search/issues with q=is:open label:bug "{title}" in:title,body type:issue (the search_issues helper in the GitHub reference; type:issue excludes PRs - the Search API returns both otherwise).

3b - Test-name search (score 0.9 on a body hit): bugs filed from CI typically embed the test path in the body - search for "{test_classpath}::{test_name}" over the lookback window.

3c - Stack-fingerprint fuzzy match (score 0.7 top-frame match / 0.4 error-class-only match): normalise the top frames of the stack (drop line numbers, drop local paths) and compare against recent bugs' bodies:

import re

def fingerprint(stack):
    top = stack.split("\n")[0:3]
    return [re.sub(r":\d+", "", re.sub(r"/Users/.+/", "", line)) for line in top]

3d - Allure-tag overlap: if the candidate has Allure labels (suite, feature, severity), score candidates by tag-set Jaccard similarity.

Decision rule: a candidate with combined score >= 0.7 is a duplicate - do not file a new issue; attach a recurrence comment to it instead. Fingerprinting is heuristic (two bugs with the same top frame may be different root causes), so include the match reason in the comment. If the best hit is a CLOSED issue, comment with "consider reopening if recurrence" rather than silently attaching - closed doesn't always mean fixed. Never skip the search because the test is a known flake - a real bug can masquerade as one. Cap lookback to LOOKBACK_DAYS; never search unbounded.

Step 4 - File or comment

No duplicate found - create a new bug via bug-tracker-workflow:

• Jira: POST /rest/api/3/issue with ADF-wrapped description (plain text passed to ADF paragraph node; the description field requires Atlassian Document Format).
• Linear: issueCreate mutation; set priority from the integer enum (1=Urgent / 2=High / 3=Medium / 4=Low per linear.app/developers/graphql (opens in new window)); resolve stateId by type = "unstarted" via workflowStates query - never hard-code state names.
• GitHub: POST /repos/{owner}/{repo}/issues with bug, severity:{level}, and priority:{pN} labels; set X-GitHub-Api-Version header.

Duplicate found - post a recurrence comment with the CI run URL and artifact link. Do not create a new issue.

Output format

## ci-defect-filer result

**Artifact:** <path>
**Failures processed:** <N>

| # | Test | Action | Issue | Match score | URL |
|---|---|---|---|---|---|
| 1 | <class>::<name> | created | ENG-1234 | - | <url> |
| 2 | <class>::<name> | commented (duplicate, 0.92: exact title + test name) | ENG-1180 | 0.92 | <url> |

**Auth warnings:** <any missing optional fields>

Refuse-to-proceed rules

• No failure artifact path supplied - refuse; will not generate a report from a prose description.
• Artifact file does not exist or is zero bytes - refuse; empty or missing input produces an unfiled spec with no ground truth.
• Required auth env vars missing for the target platform - refuse and list the missing vars.
• Uncited input (no canonical source grounded spec from Step 1) - refuse; do not file a structurally empty report.
• Failure artifact is a passing test run (all <testcase> elements have no <failure> or <error> child, per the JUnit schema at llg.cubic.org/docs/junit/ (opens in new window)) - refuse; nothing to file.

Anti-patterns