* Handle HTTP 202
Fixes#564
After some testing, it seems GitHub seems to be able to process the chrunching of statistics
for every repository I tested in around 2 seconds. So a delay of around 5 seconds should be
plenty to be very certain that the next try should succeed.
Another option would be to put this value lower and possibly waste an extra retry on it.
* Only re-request data if HEAD or GET (those are 'safe')
to e.g. avoid running a duplicate POST or PUT, that can change stuff on the server
Using RFC 2616 and https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html as guideline
* Fix testStatistics
* change wait time to 2 secs
The API docs for Repository.get_git_tree specify that the URL parameter
for fetching a tree recursively should be ?recursive=1, not a truthy
value. To not change the API we present, check if it is True before
setting it to 1. Change another callsite of Repository.get_git_tree to
specify recursive=False to make sure it doesn't appear in the query
string.
Fixes#560
The description attribute handling requirement is
a custom media type in the Accept header:
application/vnd.github.symmetra-preview+json
Limitation: Repository.get_labels does not report description,
possibly something has changed in the preview API.
* Added is_draft and is_prerelease property to GitRelease
* Added target_commitish option to Repository.create_git_release()
* Added test for Repository.create_git_release()
* Renamed attr of GitRelease: is_draft, is_prerelease -> draft, prerelease
* Add flag for maintainer can modify when creating pull requests
* Change default to be None to let github decide the behaviour
* Update docstring
* Follow conventions from other functions
This lets users do the following without issuing an unnecessary request:
issues_of_my_repository = g.get_repo('PyGithub/PyGithub').get_issues()
Since the GithubObject layer handles laziness transparently, lazy
loading is enabled by default, and can be disabled via the `lazy`
kwarg. This does not affect any test except tests that pertain to
caching or laziness itself.
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.
Maarten Fonville