I’m using GitHub and branches, tags and pull requests that I create in my parent repository are not created in the connected modules. I have branch protection set up on my modules which requires all commits to be merged through a pull request. When I merge a pull request in my parent repository the changes are reset because they can not be merged in to my modules because the pull request has not been created in the module.
Hello @Myloc-GitHub,
Thanks for trying out Git X-Modules and sharing your feedback with us.
I’m using GitHub and branches, tags and pull requests that I create in my parent repository are not created in the connected modules. I have branch protection set up on my modules which requires all commits to be merged through a pull request.
Please note that Git X-Modules do not automatically create branches and tags in module repositories when you create new branches or tags in your parent repository.
For example, if you have added a module in your parent repository:
branch branch1 at parent.git:
module modules/module1 is synced with branch foo at module.git
when you create a new branch branch2 at parent.git from branch branch1, then the module is still there but it’s not synced with any branch at module.git:
branch branch2 at parent.git:
module modules/module1 is not synced with any branch
in order to enable the sync for branch branch2, you have to go the X-Modules settings page, select branch2 there and specify a branch in module.git to be synced through our app. You can specify foo branch there and the sync goes on.
The same applies to tags.
Regarding the pull requests: at the moment the Git X-Modules app works with branches, tags and commits only, that is, it syncs commits across branches and tags. So, if you create a pull request in a parent repository and both source and target branches are properly synced with some branches in a module repository, our app won’t try to create corresponding pull request in a module repository, just because the pull requests are out of our scope at the moment.
As far as I understand, our app is unable to properly sync branches and tags between your parent and module repositories, because your module repositories have branch protection enabled. That means the Git X-Modules app tries sending commits extracted from your parent repository to a branch in a module repository, but GitHub rejects the direct push to that branch.
The same occurs when you merge a pull request in a parent repository. Technically, it’s just an update to a branch in a parent repository and Git X-Modules tries syncing this ref update with module repositories, but fails to do so because of the branch protection rule.
Unfortunately, the Git X-Modules app requires direct push access to both parent and module repositories, otherwise it’s unable to perform proper sync between the specified branches and tags. That means you’d need to allow our app to perform direct pushes to the branches in your module repositories:
-
If you’ve configured our app for an organization account, you can add the Git X-Modules app to a list of users, teams and apps who are allowed push to the protected branches bypassing the protection rules:
Managing a branch protection rule - GitHub Docs
See #14 there: Restrict who can push to matching branches; you can find this setting at your protection rule settings page. -
If you’ve configured our app for an individual account, the option above in unavailable, unfortunately, so you’d need to disable the protection rules for the branches in your module repositories synchronized with the parent repository.
Theoretically, it’s possible to create a pull request for a branch in a module repository rather than performing a direct push to that branch when corresponding changes arrive to a parent repository. So, that could be a setting for an X-Module – opening a pull request rather than pushing changes to a branch directly. That could work in the opposite direction as well – changes from a module repository could be applied as a pull request in a parent repository. We’ll definitely consider that option since we already support pull requests in case of sync conflicts.
Let us know if that would work well for your scenarios. Also, let us know how would you expect Git X-Modules to behave when you create a pull request in a parent repository – before merging this pull request and then after merging it. Especially, for the case when pull request’s target is synced with a protected branch in a module repository.
Thanks for the help @semyon.vadishev,
I had the setting Do not allow bypassing the above settings activated. I was able to make it work by disabling it and now the commits are syncing as expected.
It was this that made me think that the branches and tags would be automatically created in the module-repositories.
I’m not sure how I would expect the pull requests to work. It feels like it might get a bit complicated if the repositories where the changes will be synced in to requires a review and especially if the review settings differ between the repositories.
You wrote that it’s possible to sync branches, tags and commits and I’ve seen images that shows it, but I can only select branches for the parent- and module-repositories even if both repositories contain atleast one tag and multiple commits. Is that a limitation with the GitHub-integration or is there something I have to do?
Thank you for the update @Myloc-GitHub,
I wonder if Git X-Modules bot is automatically allowed to push commits to the protected branches when this check box is disabled. Have you added our app into the list of those who can push to the protected branches bypassing the protection rules or has the sync started to work properly without adding our app into the list?
Right, it must work this way and it’s supported by the source code of the underlying library. The problem is that our GitHub integration has no proper UI for specifying the branches mapping yet. So at the moment you’d need to specify all the module branches explicitly in the module settings.
Thank you for the feedback. I agree, things get complicated when a parent pull request gets split into multiple pull requests in module repositories, some of the module requests may get applied separately leaving the parent pull request partly applied. So far we decided to keep things as simple as possible in this regard, so we just don’t sync any pull requests across repositories.
This is the UI limitation we have at the moment. I think it makes sense to raise the priority for that feature now as there’s noticeable interest from you and other users. We’re going to implement the UI for that as follows:
when you configure a module for a given parent branch, you’d be able to specify a list of ref rules, e.g.:
if refs/heads/master sync refs/heads/master
if refs/heads/* sync refs/heads/parent/${1}
that basically means:
- If master branch points to a commit with this module, then the module directory gets synced with master branch in a module repository;
- If branch foo points to a commit with this module, then the module directory gets synced with refs/heads/parent/foo branch in a module repository.
So, if you create a new branch foo in a parent repository, X-Modules automatically creates refs/heads/parent/foo branch in a module repository and these branches are kept in sync for a given module.
Does that sound reasonable to you? Your feedback is very welcome. Thanks!
It seems that it is automatically allowed to push because I didn’t have to add it to the list of those who can push to the branch and I didn’t add it to the list of those who can bypass the pull request rules. I don’t know if that is in your implementation or if it is GitHubs implementation of apps but it would feel safer if the app had to be added explicitly to the lists.
Yes that sounds reasonable.
So far I feel like I have been able to set up my test-repositories like I want and it seems to work like I expect it to. I will start setting up our real repositories in the next few days which will have a bit higher complexity than the tests I’ve been using now with more modules and repositories that are both parents and modules. Hopefully everything will work which would simplify our workflows quite a bit. If I run in to more questions I’ll come back and create other topics.
Thanks for your help @semyon.vadishev
We didn’t implement anything specific in this regard, so it’s GitHub that allows the apps to bypass branch protection rules when the check box you mentioned is disabled.
I’m glad your testing goes well and thank you a lot for your feedback!