Why gate the issue on the quality gate instead of every finding?

A new finding isn't always actionable; a failed gate is the project's own line for what blocks a merge. Keying on the gate keeps Linear to the failures the team already agreed matter.

Can it assign the issue to whoever broke the build?

Not from the gate status alone. The agent can pull the SCM blame with get_scm_info on the offending files and map the author to a Linear user, then set the assignee on create_issue.

SonarQubeLinear

Open a Linear issue when a SonarQube quality gate fails

A SonarQube + Linear agent flow

A red quality gate in SonarQube means a build introduced coverage gaps or new bugs, and the usual outcome is that nobody acts on it until a reviewer happens to notice the badge. Tracked as a Linear issue, it becomes work someone owns. The agent checks the gate with get_project_quality_gate_status, and when the status comes back as failing it opens a Linear issue with create_issue in the team that owns the project, titled with the project and the conditions that broke. SonarQube reports status on request, so the agent runs this after a scan completes or on a schedule, and a gate that is already failing and already tracked doesn't spawn a second issue.

The flow

SonarQubeget_project_quality_gate_status

Gets the quality gate status for a SonarQube project.

Linearcreate_issue

Creates a new issue or sub-issue with title, description, and workflow metadata.

Step by step

Read the gate
The agent calls get_project_quality_gate_status for the project key and reads the overall status plus the failing conditions, such as new-code coverage below target or new blocker issues.
Open an issue when it fails
If the status is failing, the agent calls create_issue in the owning Linear team with a title naming the project and a description listing each broken condition and its actual versus required value.
Avoid duplicate issues
Store the project key against any open Linear issue the flow created. On the next check, skip projects that already have an open issue, and let the agent close it when the gate returns to passing.

Tell your agent

After each main-branch scan, get the SonarQube quality gate status for project acme-api. If it failed, create a Linear issue in the Backend team titled with the project and the failing conditions, with a description listing each condition's actual and required values. Don't open a second issue if one is already open for that project, and close it when the gate passes.

Setup

This flow needs both servers connected to your agent. Follow each install guide:

SonarQube install guide Linear install guide

Worth knowing

get_project_quality_gate_status reports the gate result and which conditions failed, not the full issue list. To attach specific findings, the agent follows up with search_sonar_issues_in_projects for that project.
create_issue needs a team ID, not a team name. Resolve it once with list_teams and pass the ID so the issue lands in the right place.
A gate can flip back to passing on the next commit. Decide whether the agent closes its issue automatically or leaves it for a human, so a transient failure doesn't churn the board.

Questions

Why gate the issue on the quality gate instead of every finding?: A new finding isn't always actionable; a failed gate is the project's own line for what blocks a merge. Keying on the gate keeps Linear to the failures the team already agreed matter.
Can it assign the issue to whoever broke the build?: Not from the gate status alone. The agent can pull the SCM blame with get_scm_info on the offending files and map the author to a Linear user, then set the assignee on create_issue.