It seems there should be an easy way to use gitlab or github as a public read-only proxy to changes that are released on the private repo. And then going the other way, sucks up PRs from public sites and lovingly integrates them into the "real" repo on my home machine.
Yes. There are security ramifications. There are availability ramifications. I seems slightly to be trying to skirt GitLab's policies they're probably putting into effect to avoid going bankrupt. But the flip-side is I really don't need a wiki or a bug tracker or whatever else GitLab is working on. I would pay a small amount of cash to just get a public repo mirror.
And we all have different ideas about how to make this "easy". I don't mind running scripts on my local host, but would like to avoid polling the public repo to see if someone's posted a PR. I also don't want to have to run a script in a container on the public repo. So would love it if you could set the public repo to proxy PRs to a remote repo.
Just curious if anyone else has similar requirements. Maybe you have a corporate repo and want to mirror it to a public site like GitLab, GitHub or SourceHut. Maybe, like me, *you* just want a remote repo to stash your code but a public location so your home server doesn't melt down that one time someone slashdots your project.
If you are hosting game binaries or Shrek the 3rd we might have some problems, but if you have a genuine source code project that shouldn't be a problem unless you become a DDoS target.
[LOL. A previous edit autocorrected "autopush" to "autopsy." Or maybe it was a Freudian slip on my part.]
Thanks for the suggestion, though. I may go ahead with something like this.
That is the one thing you can’t disable on GitHub unless something changed recently. Very annoying for mirrors where development happens elsewhere.
1) You can set up Github Actions to automatically close pull requests: https://github.com/marketplace/actions/close-pull-request
2) You can use "interaction limits" (in repository settings, under "moderation options") to limit repository interactions to collaborators. This can only be set for 6 months at a time, though, so you'll need to reactivate it periodically.
3) You can archive the project and unarchive it temporarily when making changes, disabling all activity on the fork.
You might find it easier to manage those permissions with gitolite if you want to restrict the users to just git access, and to just some repos.