Cross-repository (or, project-level) PR with multiple branches from different repositories

[achimnol]

With the introduction of the new projects and considering my organization's multi-repository workflows, I'd like to bundle multiple topic branches in different repositories under a single PR, review them together in a single view (multiple file trees in the "files" tab).

The status of PR would be an aggregation of the branch status: closed if all belonging branches are either merged or closed.

Related discussions:

• Issue-PR linkage
  • Apply "AND" of multiple linked PRs for a single issue to be closed or allow non-closing linked PRs #9926
  • Idea for linking PR <=> ISSUE #4619
  • If we have cross-repo PRs, we don't have to make any special changes to PR-issue linkage. This could be an alternative option to have instead of cross-repo PR, but still, I'd like to review multiple branches from different repositories together in a single place.
• Cross-repo (or project-level) issues and milestones
  • Project level milestone #5685
  • Project Beta: ORG wide labels #5417
  • [Projects Beta] Create milestones and labels from Projects? #6040
  • [Projects Beta] Milestones Across Repositories #6296
  • Allow issues to belong to a project and be "linked" to multiple repositories #6433
  • [PROJECT BETA] Allow labels & comments for the items not belonging to any repository. #11285
  • If we have cross-repo PRs, we also need to consider making labels and milestones to be project-wide and/or org-wide.

In my case, individual repositories are dedicated to individual Python packages, but the whole project works with at least 5 of them to be installed together. (Imagine OpenStack's distributed, multi-component architecture.)
I and my colleagues often forget to update a component among those 4-5 components when working on a topic, and when reviewing the same also happens.

As an alternative, I have investigated another way: the mono-repository approach, but this complicates the CI workflows too much.

[kuehnfelix]

This would be awesome. Would solve a lot of issues in the multi repo workflow. Especially for automated testing across repos

[dpec2005]

Yes @kuehnfelix,
this would solve a lot of problems. In my team we are currently facing a lot of problems with our repository-structure.
Different parts of the system (similar to micro services) are in submodules that are tracked in one full-system-repo. Some of those submodules require each other in dependency-chains. Making changes in two or more submodules at the same time often interferes with our current ci-workflows. We are even considering, creating a system for linking pull requests from scratch with GitHub actions and a separate "ci-server" or like @achimnol mentioned, changing our structure to a mono-repository losing the ability to quickly find commits in the history, since everything is mangled together.
Both of these options are terrible, since the first "solution" would cost us a lot of time and I already mentioned the issue with the second option. So please, make this happen.

[JamesMenzies]

What a lovely idea. I think Sounds so much more elegant than diving into monorepo. If I was going to build tooling I would much prefer to do this than yet another attempt to make giant repos work.

[jdeastwood]

Sounds so much more elegant than diving into monorepo

Honestly I think that this idea -- perhaps combined with some sort of ability to have cross-repo github actions triggers and required statuses -- is the "monorepo" idea translated to git/github.

It's possible that most discussion about monorepos gets a bit hung up on the mono and repo bit whereas I think that might just be an implementation detail. I can imagine a "google monorepo" style system based on git in which a single git repository (and by extension github UI) is roughly equivalent to a workspace in the google monorepo.