Create one pull request across several repositories

[David]

We have a Stash Project with ~30 repositories, each containing one submodule. The root-repo (the one holding the git submodule configuration) is also contained in the project. During development we almost always need to change code in more than one module, so we have to create pullrequests in each submodule separately, even if they belong to the same ticket/changerequest/userstory/bugfix.

So, is it possible to create one pull request for changes in multiple repositories?

Thanks!

[Steven Whitman]

We have a similar situation with pull requests and submodules.  Even without the submodule aspect there may be situations where a global project change may require that the repositories are updated in a specific sequence.  For example for repository B should be merged then repository A should be merged, etc.  Being able to put conditions on a pull request merge might address the OP requirement.  If one could say, pull request A can't be approved and merged until pull B is approved and merged that would at least prevent an out of order issue.  It doesn't address the OP desire to create a single pull request but it means that multiple pull requests are completely independent which might minimize the issue of creating multiple requests.

[David]

Yes, some kind of "pull request set/bundle" would be a really nice feature even for a single repository.

[Balázs Szakmáry]

You can create a feature request for this at http://jira.atlassian.com (check first if one exists already). Please post the link here in a comment if you do.

[yamashitagensuke]

for a self hosted bitbucket should i just create on bitbucket cloud ?

[Mike Friedrich]

i dont think thats possible, because pull-request merges create always a new commit.
And those new commits in the submodules are not the those you have linked in the "parent" pull-request's commit.

In other words: You need to merge the commits in the submodules first before you can even link them in the parent repository.

Nonetheless, it might be beneficial for your scenario if Stash could group several independend pull-requests into one user action.

[Tom_van_den_Broek]

I think hierarchially linked pull requests are the answer. The pull request is defined based on branches, not commits. Child just needs merged transition to trigger parent Pull Request.

For reviewer it should still be ok, because they are looking at the diff introduced by the software change.

[Alex Bondar]

We have faced a similar limitation of the Bitbucket when the project is composed of many repositories that have the same development lifecycle. Thus, to simplify the life of a build-engineer who has to apply mostly the same operations to a bunch of repositories we wrote bash scripts that automate those things with the help of Bitbucket API.
https://github.com/ab0ndar/bitbucket

[Tim Black]

Thanks, @Alex Bondar . I've seen other examples of teams rolling their own "client-based" solutions like this. After my deep dive into server side solutions (using existing plugins and/or rolling our own with the Atlassian SDK), I see the virtues of a client-based solution like yours.

A client-based solution provides simplicity at the expense of elegance. 

Your users have the extra step (and process to enforce) of running a PR-creation script instead of using the Bitbucket UI for PR creation. This aspect is less elegant than the (hypothetical, non-existent) server-side solution wherein:

The Bitbucket UI for PR creation is modified to automatically observe when (a) the repo contains submodules, and (b) the submodule references have changed in the PR changeset, and then (c) automatically and correspondingly create PRs for the submodule repos.

However, the client-based solution is simpler and certainly more pragmatic since it's easier to attain in short time, and has the added benefit that there is less configuration on the server to maintain. The client-based solution is simply a script that is shared with developers in SCM/git.

Thanks again for sharing your `pr-create.sh` solution. :-) I will probably use it as a starting point for our solution. Perhaps I will fork your repo and contribute. We're using Bitbucket Server 6.10, and it will be interesting to see if anything in your scripts is Cloud-centric. EDIT: also I see now that your solution for creating a PR doesn't do anything with submodules, but instead created PRs for all repos in a Bitbucket Project. This is less interesting to me, since we don't have the convenience of all submodule repos being in the same Project, but should still serve as a good starting point. Thanks again. 

[Craig Hewetson]

I would like this feature too. 

I have attached the jira issue that is 99% the answer to this question (as I have interpreted it) 

https://jira.atlassian.com/browse/BSERV-4577

Maybe the people who voted for this answer should vote for the feature request too.

[Tim Black]

@Craig Hewetson I agree completely! Note, there is also BSERV-9660, created a few years later.

We need to consolidate these efforts to bring Atlassian to more seriously consider providing a solution to gluing together PRs in super-repo and submodules in one atomic action. This is a significant obstacle for anyone using modern software development/CI practices and has a non-trivial project that is forced to use submodules. 

Gitlab 12.2 released this functionality in August 2019, and I endorse their solution, documented here.

[Tim Black]

I see now that BSERV-9660 is more about collecting superrepo/submodule PRs, whereas BSERV-4577 is more about collecting arbitrary PR dependencies (like what Gitlab Premium now supports).

I am more interested in BSERV-9660, and have reached out to Atlassian support to escalate it, and am taking a dive into the Bitbucket API/SDK to learn about way to implement this myself.

[David]

Sounds great. The branch names are equal, yes (e.g. feature/#123456_foo). Would that require to use ScriptRunner or create a separate addon for Stash?

[JamieA]

It could be done with a little bit of code... what links the different changes, do they all have the same branch name for instance?