Allow connecting multiple GitHub repositories to a single project

ROA-155

Original GitHub comment

Nice suggestion, I will do that, sounds like a cool idea.

Original GitHub comment

Related: #1282 is the same multi-repo capability for the Gitea integration, and #1318 is the adjacent request to add GitLab as a provider. A shared integration-layer design could cover the multi-repo ask across providers.

Original GitHub comment

Adding a concrete use case, since this is currently priority:low.

We just migrated off Linear onto self-hosted Kaneo and hit this immediately.

Our setup is one Kaneo project whose slug is the ticket prefix (ABC), because the identifiers ABC-1…ABC-n are referenced everywhere — commit messages, branch names, PR titles, external trackers, and years of prose. Those identifiers are per-project ({slug}-{number}), so splitting into one project per repository would restart numbering and break every existing reference. That makes the obvious workaround a non-starter for anyone migrating an existing history rather than starting fresh.

But the work behind those tickets spans four repositories. With one repo per project, at most one of them gets branch/PR automation; the rest are manual.

Worth noting the branch matcher already handles multi-repo cleanly — it lowercases the slug and compiles case-insensitively with an optional suffix, so branches match without any per-repo config. The only thing that's single-valued is the repository binding itself (repositoryOwner / repositoryName on the integration, plus UNIQUE (project_id, type)).

Re: your note about a shared integration layer across #1282 and #1318 — from our side the useful shape would be a project ↔ repositories one-to-many, with automation rules staying at the project level rather than per repo. We don't need per-repo rule overrides; the same "PR merged → Done" applies regardless of which repo the PR is in.

Happy to test a branch if that helps.

Original GitHub comment

+1 this

Original GitHub comment