-
-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pull request / CI workflow #24
Comments
Hi @fabpot - do you have any suggestions here? Is this something the non-lite version of splitsh does? |
This is out of the scope of this project. The full version helps moving PRs from the many repositories to the main one (not the other way around though). I might open source this feature as another command in the future if there is enough demand for it. |
@fabpot is there a centralized place you are keeping track of interest for this other than just emailing you? I've seen your talks on what appears to be a "full" version of split.sh and it looks exciting. |
@fabpot Would you be willing to describe at a high level how this command works? Perhaps with guidance an interested party could develop a PR for this feature. Thanks! |
@fabpot any updates on open-sourcing the full version or at least the feature for moving PRs from the many repo's to the main one? |
Requesting update also :) |
This works in theory because splitsh is stable in its resulting commit hashes. A commit made to a sub-repo moved up to the monorepo then back again should retain the same hash. I'll document the progress I've made with this. Split the mono-repo into two repositories and add them as remotes to the original monorepo. Pushing the branches to their respective remotes.
A PR will happen against subrepo-1. From the monorepo's context (with subrepo-1 added as a remote so it has access to the commits), iterate over each commit of the PR in order. Cherry pick the commit with the subtree option set, fastforwarding.
Explicitly grab all the data of the original commit and 'transfer' it to the cherry picked commit.
This works as described in the slides with single commit PRs, the commit hash collides and the PR is automatically 'merged' by github. When the commits are signed this doesn't work. You can view how the commit hash is generated with:
Pass the output to that with If the commit is signed the gpg signature will be embedded in there. I feel like it should be possible to keep that around? But it would have to survive a round-trip through splitsh. The signing signature would then fail in your monorepo but be valid in the public one? It also doesn't seem to work properly if there are multiple commits in the PR. Hitting 'rebase and merge' in the github UI doesn't create any new commits and marks it as merged however? |
Hi all,
Has anyone figured out how to combine mono/manyrepos with GitHub pull requests and CI? For my non-monorepo projects, each PR automatically gets built by Travis, which helps a lot with screening of pull requests.
I've got CI for all the manyrepos, but nothing in the monorepo where all PRs are received. Are there any tricks to automatically migrate monorepo PRs/branches to manyrepo PRs/branches? Any smart git hacks?
Cheers,
Aslak
The text was updated successfully, but these errors were encountered: