search

octokit / octokit.rb

Ruby toolkit for the GitHub API
http://octokit.github.io/octokit.rb/
MIT License
3.84k stars 1.14k forks source link

Add support for protected branches API #802

Closed aspiers closed 2 years ago

aspiers commented 8 years ago

As everyone knows, GitHub recently released a new code review system. It's now possible to protect a branch so that a PR to that branch can only be merged after it has been approved by at least one reviewer and had no disapprovals. However AFAICS it's not possible to get or set this configuration parameter via the API, let alone via Octokit (I've filed isaacs/github#781 for that). So this is a placeholder issue for updating Octokit once that API has been provided.

kytrinyx commented 7 years ago

I believe this is now supported in the API: https://developer.github.com/v3/repos/branches/

It doesn't look like it has been added to octokit yet.

pengwynn commented 7 years ago

@kytrinyx I think @tarebyte added those methods here.

kytrinyx commented 7 years ago

@pengwynn there are a lot more endpoints in the API docs than what we have there. I'll take a look at what's missing.

jblac commented 7 years ago

I use protected branches myself, I'll be updating my PR #890 with the necessary endpoints for the reviewers' portion of this, but can definitely look into building out more options in different PR's if we can figure out functionality and what we're missing in octokit that's currently available in the API.

nickfloyd commented 2 years ago

Hey, @aspiers thank you for the effort here. Given this has been out for close to 5 years and many changes have been added since this was first introduced, I am going to close this issue and mark it as stale. If you feel strongly about this needing to be implemented please feel free to reopen and make the changes stated above and we'll do what we can to get it merged in. Thanks again!

aspiers commented 2 years ago

Thanks for the response @nickfloyd. I don't personally have a strong need for this right now, and unless that changes, sadly probably won't have time to implement it any time soon. But of course I'll come back here if the situation does change.

On a more general note, my personal recommendation (which of course you are free to take or leave) is that it is often more productive to leave issues open until there is a clear resolution (e.g. a fix, or a decision such as "we're not going to implement this").

When issues or feature requests are marked as closed without resolution, then people are more likely to miss them, resulting in duplicate reports. And people searching for ways to contribute are more likely to miss them too. Here's someone else's blog post on the same topic.

However I understand it is annoying to have open issues going nowhere. IMHO one solution for this is to label short-lived and long-lived issues differently to distinguish them. Another is assigning issues to different milestones. This makes it clear to users which issues are likely to be fixed sooner rather than later.

Hope this is useful food for thought. Thanks again!

nickfloyd commented 2 years ago

Hey, @aspiers Thanks for the tips - I'm going to give them some thoughts and potentially implement some of those labeling changes in all of the octokit libs to help us keep things straight.