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?
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.
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.
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.
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.
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.
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.
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.
Hi everyone, We are looking to learn more about development teams’ workflows and pain points, especially around DevOps, integrations, administration, scale, security, and the related challeng...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events