Linear to GitHub pull requests with n8n: the pipeline, stage by stage.
Linear to GitHub pull-request automation with n8n is a pipeline in which Linear holds the tickets and their state, n8n orchestrates, a GitHub Action writes the code and tests, and a person approves every merge. Paul Rahme built and runs this one at the marina-software client. The same design ports to Jira or Azure DevOps, GitLab or Bitbucket, and Zapier or Make. Marina-software ticket-to-PR case study (about 2× faster) →
Every ticket rides the same conveyor belt
n8n owns queueing, state, and notifications. GitHub Actions owns the coding and the build. Keeping them apart is what makes the whole thing debuggable.
Intake
A ticket in Linear is opted in by a label. Two doors: a scheduled poll that picks up a capped number of labelled Backlog tickets per day, and a Linear webhook for instant pickup the moment a human adds the label.
Triage
Freshness guard (is it really a new candidate), clarity check (is there enough detail to attempt; if not, a label asks for it), duplicate check against in-flight tickets. Tickets that pass move to Todo.
Dispatch, one at a time
The dispatcher waits if anything is already In Progress, picks the oldest Todo, maps the ticket's project to the repositories and branches the agent may touch, sets In Progress, and fires a GitHub repository dispatch.
The worker
A GitHub Action clones, plans, implements, reviews its own change, writes tests, and opens the pull request or requests. It never merges.
Build gate and retry
For desktop projects a compile runs on Windows. Green moves the ticket to AI Review and pings the tester in Teams. Red triggers the retry loop: the agent reads the failure and fixes its own PR, up to a limit, then hands to a human.
Merge, QA, watchdog
A human merges. When all PRs are merged the ticket moves to QA Review with a tester assigned. A watchdog every 30 minutes flags anything stuck for more than an hour and nudges the queue.
The whole system runs on Linear's own vocabulary
No new tool for the team. A ticket's state column and its labels are the only things the automation reads and writes, so anyone can see where a ticket is and why.
The retry loop in detail: what the agent does with a red build
When the desktop compile fails, the ticket is flagged for a build retry and the worker is dispatched again with the failing output attached. The agent reads the compiler errors, changes its own branch, and pushes; the build runs again. This repeats up to a fixed limit, after which the ticket is labelled as needing a human and the engineer sees both the pull request and the history of attempts. The limit matters: without it an agent can loop on an error it does not understand, spending compute and hiding the problem. With it, a red build costs minutes rather than an engineer's afternoon, and the cases that reach a person are the ones that needed one.
Why one ticket at a time, and what the per-repo cap protects
Parallel agents on the same codebase create merge conflicts with themselves and make a bad run hard to isolate. One ticket in flight means one branch, one build, one thing to look at when something is wrong. The per-repository cap on open agent pull requests protects the reviewers: if the queue of unreviewed PRs grows, the dispatcher waits rather than piling on. Throughput comes from the agent working through the night, not from doing ten things at once.
Running the same pipeline on Jira and GitLab: what changes
The pipeline is states, labels, a dispatcher, a worker, and a gate, and every mainstream tracker and CI system provides those primitives. On Jira, the Linear states become workflow statuses and the labels become labels or a custom field; the webhook and the search API replace Linear's. On GitLab, the repository dispatch becomes a pipeline trigger and the pull request a merge request, with the compile step as a job. Azure DevOps and Bitbucket map the same way. What does not change is the design: opt-in by label, one ticket at a time, a build gate with a bounded retry, a human on every merge, and a watchdog. The n8n workflows swap their connector nodes; their shape stays.
Built and run on Linear and GitHub at the marina-software client; the other combinations are ports of the same design, not deployments to point at yet.
Questions engineering leads ask
Why one ticket at a time?
So the coding agent is never fighting itself across branches, and so a bad run is one bad run. Throughput comes from the agent working around the clock, not from parallelism.
Does the agent ever merge?
No. It opens pull requests and, when the build is green, asks a named person to review. Merging is a human decision, always.
Will this work with Jira and GitLab instead?
Yes. The pipeline is states, labels, a dispatcher, a worker, and a gate. Jira issues and GitLab CI provide the same primitives; the n8n workflows change their connectors, not their shape.
Where does the code and ticket content go?
Nowhere new. n8n runs on your infrastructure, the worker runs in your GitHub Actions, and model calls run through your own cloud account. Aldenebai holds no keys.
Related pages
Engineers stuck on boilerplate?
The free Automation Audit picks the ticket classes a machine should own in your codebase. 30 minutes, written Automation Map included.