The current API for changing user and teams push restrictions is
brittle, and flat out incorrect when it comes to adding members. Break
the API, but replace it with one that is correct.
Co-Authored-By: Jonas Maurus <jonas-github@maurus.net>
With the Python 2.7 deadline fast approaching, modernize the codebase
making use of the modernize module to switch to using six, as well as
other upcoming features, such as absolute imports . Stop using 2to3
for Travis, yay!
Wraps the parts of the branch protection API that allows the user to require signed commits on a branch.
New methods are :
* Branch.get_required_signatures : returns true if signed commits are required
* Branch.add_required_signatures : adds the requirements for signed commits on a branch
* Branch.remove_required_signatures : removes the requirement for signed commits on a branch
It uses the API provided on this page : https://developer.github.com/v3/repos/branches/
Since this feature is in [preview](https://developer.github.com/changes/2018-02-22-protected-branches-required-signatures/) I pass the 'Accept application/vnd.github.zzzax-preview+json' header to each request.
The GitHub API currently has a beta extension to the Branch Protection
API that allows inspection and setting of the number of required
approving reviews required for a PR to be merged. Add support for it.
The Branch protection API has been radically changed by GitHub, add new
methods to Branch reflecting it. Branch protection methods are now
called on the Branch object itself, rather than awkwardly hanging off
the Repository object and requiring branch names to be passed in.
This adds an over-arching methods to get, edit and remove protection
entirely, as well as fine-grained methods for getting, setting and
dropping certain aspects of branch protection, as well as three new
objects to encompass querying those aspects.
This also destroys Repository.protect_branch(), the endpoint has been
removed. The old-style protection attributes on Branch have also been
removed to force users onto the new API, since they are still sent, but
no longer populated.
Fixes#586
This is a minor thing. It’s a convention, not a rule (obviously)—but it’s also a best practice.
Many text editors look for this kind of comment as the first line—or second line, if there is a shebang (the `#!/usr/bin/env python`, or whatever else)—and make use of this to determine the file’s encoding.
Steve Kowalik