Turn failed Bitbucket builds into Jira bugs

When a Bitbucket Pipelines run finishes with a FAILED state, triage the failure and open a Jira bug so the on-call engineer has something actionable to pick up. The trigger is an incoming Bitbucket webhook subscribed to pipeline events. Ignore any event where the run's result state is not FAILED (skip SUCCESSFUL, STOPPED, and in-progress states).

Once a failed run comes in, gather context from Bitbucket. Call Get Pipeline to confirm the current state and pull the commit hash, branch, author, and pipeline URL. Then call List Pipeline Steps for that run and identify the first step whose result is FAILED — that is the step that actually broke. Read the raw build log for that step with Get Pipeline Step Log; the log is text/plain and can be very large, so quote only the last 40 to 80 lines around the failure marker (look for things like 'FAILED', 'Error:', 'Traceback', 'exit code', or the runner's failure banner) rather than dumping the whole log into Jira.

From that log excerpt, diagnose the likely root cause in plain English. Classify it into one of: compile error, failing test (call out flaky-looking ones), missing or misconfigured environment variable, dependency install or resolution issue, infrastructure or timeout, or 'other'. Extract the most useful signal — the failing test name, the exception class and message, the offending shell command, or the missing variable name — so it can be searched against later.

Before creating anything, dedupe against Jira. Use Search Issues (JQL) with a query like project = <ENG> AND issuetype = Bug AND created >= -24h AND (summary ~ "<key signal>" OR description ~ "<key signal>") — the key signal being the failing test name, exception class, or command that broke. If a matching ticket exists, use Add Comment to append a note on that existing issue instead of opening a duplicate. The comment body must be Atlassian Document Format (ADF), not raw markdown; include the new pipeline URL, commit, branch, and a short 'happened again' line.

If no matching ticket exists, call Create Issue in the engineering project with issuetype = Bug. The summary should be a punchy one-liner naming the failure ('Pipeline failing on main: NullPointerException in UserServiceTest.testLogin'). The description (ADF) should contain: a one-paragraph plain-English summary of what likely broke and why, the offending stack trace or command in a code block, a facts section with the commit hash, branch, author, and failing step name, and a direct link back to the pipeline run in Bitbucket. Match the team's usual labels and priority conventions if they've been configured; otherwise leave those fields alone.

Behavioral rules: never file a ticket for a SUCCESSFUL or STOPPED run; never dump the entire raw log into a Jira ticket — quote only the relevant tail; always prefer commenting on an existing 24h-old ticket over creating a near-duplicate; and treat the commit hash + failing step + exception signature as the identity of a 'root cause' when deciding whether two failures match.