GitHub Community
Request: Ability to turn off Pull Requests #8907
|
Right now you can disable Issues if you decide you don't want to accept contributions or bug reports... but that doesn't stop people from submitting PR's in the event that you still don't to accept contributions or bug fixes. Sometimes there's times we just want to share code and don't want the burden of maintaining it, triaging issues or pull requests, etc. It would be nice to have the ability to disable pull requests just like you can disable issues. More discussion and source of this request: https://twitter.com/adamwathan/status/1471151787017187331 |
Replies: 13 comments 8 replies
|
Also I feel some would argue that this is what gists are for. And that is simply not the case disabled pull requests could make it so much easier to share large or much more complex projects that normally wouldn't see the light of day due to having people make pull requests that the maintainer simply won't accept. |
|
I thought too, but can you push a file tree to a gist? And have all those lovely features of Git repositories, like navigation, method references and a readme file in the front. |
|
gists do not support folders no |
|
Saying "Use Gist instead of GitHub repo" is like saying "Use Notepad instead of your IDE". 😂 |
|
The Changelog had a great episode on this exact topic recently, definitely worth checking out; "Open source, not open contribution"
Can't hurt to at least make it an option, right? |
|
Also, Archiving and Interaction Limits are not a solution to this because I'd still like to allow issues/commits to be made, etc. |
|
So when it will be possible to disable pull requests? |
|
From #20346:
Note that FreeBSD bug 265115 is specific to the Please, do not disable pull requests (or GitLab merge requests) for the |
|
To reiterate what I have said elsewhere... This would be a very welcome feature, but I would add the caveat that it should be possible to instead restrict PRs to being a maintainers only feature. Often people make a PR that solves their immediate problem without considering the needs of others or the wider implications of their changes. Maintainers understand those needs and implications much better than drive-by contributors, so it makes sense to be able to restrict contributions to only maintainers. A workflow that consists of users making feature requests and bug reports via issues and then maintainers deciding how best to implement those features or fix those bugs will often run more smoothly than users contributing a half-baked solution and maintainers having to gently explain why they aren't going to accept the PR without seeming like the villain of the story. |
|
Very true. Several times I found myself in a discussion about a half baken solution which even introduced new issues. So restricting PRs would help to keep some level of software quality without wasting time with lost discussions. |
|
In FreeBSD maintainers don't even look at PRs, because there's another way to submit patches - Bugzilla. |
|
Definitely seems to be a feature that has been requested plenty of times (from as far back as 2016). There is plenty of use cases for this feature. Some of the main ones that resonate with me is repos that are just mirrors, where the repo has a different mechanism for contributing, or because your repo is a fork and PRs should be sent upstream instead of to the fork. Really hoping this is a feature that gets implemented. |
|
I don't want people submitting pull requests to my remote fork, and I do want people submitting pull requests to the source repository. |
|
I have a username repository (github.com/username/uesrname) for my GitHub profile's readme. No need for PRs. |
|
Reposting and expanding my comment from dear-github/dear-github#84 (comment): I also would like to disable pull requests on a repo, but for a different reason to most mentioned here: security of selfhosted runners. This is even more of a problem for us (OpenSSH) with the recent announcement that selfhosted runners on private repos will soon have a per-minute monetary cost! We have a set of self-hosted runners that run tests on various platforms for which there are no hosted runners, and based on the docs we have them attached to a private repo that mirrors the public one. I would like to be able to disable pull requests on that repo so I can make it and thus the test statuses public. We set it up this way since the action runner docs point out that the ability to create pull requests on a repo can be used to compromise the security of a runner attached to that repo. Secure use reference says:
There is an option to disable workflows in pull requests but I'm not sure if that it's sufficient, especially given that the runner docs don't mention it and have only a blanket warning against using selfhosted runners on public repos. There are Interaction Limits which allows exactly this, but only for a limited time (up to 6 months) so for my use case, having a security control that fails open after some period is extremely problematic. Please provide a way to permanently disable pull requests on a specific repo so that I can safely make this repo and its runner test results public. |
|
GitHub is finally implementing this.
|
|
release announced here #187038 |
|
Looks to be available now! Time for me to disable PRs and Actions on my mirrors, now that I don't need an auto-pr-close workflow lol |
|
It's great we finally have this. |
GitHub is finally implementing this.
https://github.blog/open-source/maintainers/welcome-to-the-eternal-september-of-open-source-heres-what-we-plan-to-do-for-maintainers/