← GitHub integration
Routing model

How Sprintra routes PRs to projects

One GitHub install, many repos, many Sprintra projects. The rule that decides which project a pull request belongs to is simple: it's based on what the PR says, not which repo it lives in.

The three-layer model

Three concepts that are easy to conflate — keeping them separate makes the rest of this page obvious.

1. GitHub install

One install per GitHub account or organization. You decide which repos that install can read from. This is a capability — it controls what Sprintra is allowed to see, nothing else.

2. Sprintra workspace

One workspace per Sprintra account. May contain many projects. Every install in a workspace is shared across all projects in that workspace — the dashboard's GitHub settings page shows the same installs whether you're viewing Project A or Project B.

3. Per-PR routing

For each pull request, Sprintra reads its title, body, and branch name. It looks for ticket references — PROJ-42, WEB-7, closes API-1, and similar. Each match links the PR to that story. The PR's repo does not constrain which project it routes to.

Patterns Sprintra recognizes

PatternExampleWhat it links
Project ticket key + numberPROJ-42, WEB-7Story number 42 in the project with key PROJ
Magic verbscloses PROJ-42, fixes WEB-7Same story link, with the semantic "this PR closes this story"
Multiple references in one PRPROJ-42, API-7Both stories — in different projects if you want

Pattern A — one repo per project

The simplest case. Each Sprintra project maps to one repo. Each repo's PRs use that project's ticket key.

Repo                Sprintra project   Ticket key
─────               ────────────────   ──────────
myorg/web           Web                WEB
myorg/api           API                API
myorg/mobile        Mobile             MOB

Install Sprintra once on the GitHub account, grant access to all three repos, discipline PR bodies to use the matching ticket key. Routing is unambiguous.

Pattern B — multiple repos per project

One project spans multiple repos. PRs from any of them use the same ticket key.

Repos                          Sprintra project   Ticket key
──────                         ────────────────   ──────────
myorg/web                  ─┐
myorg/web-electron          ├─→  Web              WEB
myorg/web-mobile           ─┘

Grant Sprintra access to all three repos. Every PR uses WEB-N. The repo doesn't matter for routing — only the ticket reference does.

Pattern C — one repo feeds multiple projects (monorepo)

A monorepo containing code for several products. PRs use different ticket keys depending on what they touch.

Repo                Sprintra projects   Ticket keys
─────               ─────────────────   ───────────
myorg/monorepo  ─┬─→  Web               WEB
                 ├─→  API               API
                 └─→  Marketing         MKT

A PR touching both Web and API code can mention WEB-42, API-7 and link to both projects.

PRs without a ticket reference

A PR that doesn't mention any ticket key is captured but not routed to any project. It appears under Unlinked PRs in the dashboard. No story status moves.

For teams that want a guarantee every PR is tracked, the simplest fix is a shared convention — branch prefix (PROJ-N-foo), a PR template requiring Closes: ____, or the auto-generated agent rules files Sprintra ships. See Conventions for the configuration set.

Next