Gatetrail

How to turn quality gate results into Jira tickets

A quality gate in SonarQube™ answers one question after every analysis: does this code meet the conditions the team agreed on? When the answer is no, the work to fix it usually belongs in Jira, where the team plans. This guide describes the common ways to get there and what each one leaves to you.

The problem

A failed quality gate is visible in SonarQube and, if the scanner waits for the gate, as a failed CI job. Neither is a planning tool. Without a ticket, a red gate depends on someone noticing it, and the follow-up lives in chat messages or memory. A ticket alone is not enough either: it has to reflect the current state. If the gate turns green again, an open ticket is noise; if it fails again after being fixed, a closed ticket hides the problem.

So whatever you choose should answer four questions:

  • Create: does a failed gate open a ticket, with the failed conditions and a link back to the analysis?
  • Deduplicate: does the next failed analysis of the same project and branch update that ticket instead of opening another one?
  • Close and reopen: does the ticket close when the gate passes, and reopen if it fails again?
  • Trust: how is the sender authenticated, and which credentials have to be stored where?

What SonarQube sends

SonarQube can call a webhook when the background task of an analysis has finished. Webhooks are set per project under Project Settings → Webhooks, or globally by an administrator. The JSON payload contains the project, the branch, the analysis time and the quality gate with its status and conditions. If a secret is set on the webhook, SonarQube signs the body with HMAC-SHA256 and sends the signature in the X-Sonar-Webhook-HMAC-SHA256 header, so the receiver can check that the delivery is genuine. The call goes outbound from SonarQube to the receiver's HTTPS URL; SonarQube itself needs no inbound access. See SonarSource's documentation on webhooks for the details of your edition.

The options

1. Tickets by hand

Someone checks the gate status in SonarQube or in CI and opens, updates and closes tickets manually. Nothing to install and full control over the wording. It works for a few projects; with many projects and branches, tickets drift from the real gate status, and duplicates and forgotten tickets are common.

2. A generic webhook with automation rules

An automation tool that accepts incoming webhooks, for example the automation in your Jira site or a separate integration service, receives the SonarQube payload and creates a ticket through a rule. This needs no extra app if the tool is already in use. You build and maintain the logic yourself:

  • react only to failed gates, and find an existing ticket for the same project and branch before creating one;
  • update, close and reopen that ticket as later analyses arrive, in the right order;
  • authenticate deliveries: check whether the tool can verify SonarQube's HMAC signature, or how else it makes sure that only your SonarQube can create tickets;
  • keep the rule working when the payload, the Jira workflow or the required fields change.

3. An app from the Atlassian Marketplace

Several apps on the Atlassian Marketplace connect SonarQube and Jira, and they work in different ways. When you evaluate one, these questions tell them apart:

  • Does the app need network access to your SonarQube, or does SonarQube send to the app?
  • Where is a SonarQube token stored, if one is needed at all?
  • Does it need a step in your CI pipeline?
  • Does it update, close and reopen tickets, or only create them?
  • Which SonarQube editions and versions are supported and tested?

How Gatetrail does it: the webhook alone

Gatetrail for Jira is a Marketplace app built on Atlassian Forge, offered to businesses only. For quality gate tickets it uses only the SonarQube webhook, so the setup needs a Jira administrator and someone who can administer the SonarQube project, and no change to your CI pipeline:

  1. Install the app and open Jira settings → Apps → Gatetrail. Generate the webhook secret and bind a SonarQube project to a Jira project, with issue type, labels and field defaults.
  2. In SonarQube, add a webhook to the project with the trigger URL and the secret from the admin page. The admin page also shows a ready-made curl command for the SonarQube API.

From the next analysis on:

  • A failed quality gate opens one ticket per project and branch, with the failed conditions and a link to SonarQube.
  • The ticket is updated while the gate stays red, closed when it turns green and reopened if it fails again. Each ticket carries a fingerprint of project, branch and group, so a repeated delivery updates the existing ticket.
  • Every delivery must carry a valid signature made with your webhook secret; deliveries without one are rejected. Each SonarQube server gets its own trigger URL and secrets.
  • The ticket shows the gate, its status and the analysis time in an issue panel and is searchable with JQL, e.g. qualityGate = "failed" or sonarProject = "my-project".
  • No SonarQube token in Jira: SonarQube sends to the app, outbound over HTTPS, and needs no inbound access.

The step-by-step setup is in the documentation.

What the relay adds

A quality gate says that something is wrong, not which findings to fix. For that, Gatetrail has an optional relay, a small open-source command-line tool that the team owning the CI pipeline runs after the scan. It reads the open findings from your SonarQube with a token that stays in your CI and pushes them to the app, signed and outbound. With the relay, in addition:

  • Finding tickets grouped by rule, updated, closed and reopened with every analysis, with a minimum severity per project.
  • A one-off import of existing findings, with a dry run first.
  • Fix deadlines per severity, searchable with JQL; overdue tickets get the label sla-breached.
  • Risk decisions: approvers accept a risk or mark a false positive in Jira, with a mandatory reason; decisions are signed, logged, exportable as CSV and written back to SonarQube.
  • Overviews: a project page, a dashboard gadget and a printable portfolio report.

See Add the relay to your CI in the documentation.

Requirements

  • Jira Cloud.
  • SonarQube Community Build (tested with 26.9) that can send webhooks to the app's URL over HTTPS; or SonarQube Cloud (tested October 2026; the Free plan analyses the main branch only); SonarQube Server is not yet tested.
  • For the relay only: a CI pipeline that can run Node.js 22 or a container and reach your SonarQube.

Questions or a pilot for your business: support@gatetrail.com.