Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP add statuses iterator to pull requests #896

Open
wants to merge 4 commits into
base: master
from

Conversation

@markddavidoff
Copy link

@markddavidoff markddavidoff commented Oct 16, 2018

No description provided.

@markddavidoff markddavidoff force-pushed the markddavidoff:add-pr-status-iterator branch from 54938dc to 3b5bc2b Oct 16, 2018
src/github3/pulls.py Outdated Show resolved Hide resolved
@jacquerie
Copy link
Collaborator

@jacquerie jacquerie commented Oct 16, 2018

Also, tests are a must! You can have a look at

def test_commits(self):
"""Show that a user can retrieve the commits in a Pull Request."""
i = self.instance.commits()
self.get_next(i)
self.session.get.assert_called_once_with(
url_for('commits'),
params={'per_page': 100},
headers={}
)
for an example of how to write a unit test for an iterator method on a PullRequest object, and
def test_commits(self):
"""Show that one can iterate over a PR's commits."""
cassette_name = self.cassette_name('commits')
with self.recorder.use_cassette(cassette_name):
p = self.get_pull_request()
for commit in p.commits():
assert isinstance(commit, github3.repos.commit.ShortCommit)
for an example of an integration test. Finally, https://github3.readthedocs.io/en/master/contributing/testing.html contains some helpful information on the general testing strategy for this library, but feel free to ask any question you might have.

@markddavidoff
Copy link
Author

@markddavidoff markddavidoff commented Oct 16, 2018

Will add tests!

@markddavidoff markddavidoff changed the title add statuses iterator to pull requests WIP add statuses iterator to pull requests Oct 18, 2018
@@ -575,6 +576,21 @@ def reviews(self, number=-1, etag=None):
url = self._build_url('reviews', base_url=self._api)
return self._iter(int(number), url, PullReview, etag=etag)

def statuses(self, number=-1, etag=None):
"""Iterate over the statuses associated with this pull request.

This comment has been minimized.

@markddavidoff

markddavidoff Oct 18, 2018
Author

add a .. versionadded:: 1.3.0 to reflect when this function was added to the API.

:rtype:
:class:`~github3.repos.Status`
"""
return self._iter(int(number), self.statuses_url, status.Status, etag=etag)

This comment has been minimized.

@sigmavirus24

sigmavirus24 Oct 19, 2018
Owner

Everywhere else we build a URL, (search for _build_url in this file for example) but here we're using the URL returned by GitHub. In the past they've been flat out wrong. GitHub recommended to me to just build URLs from scratch. That says to me that we should take a look at what this looks like now, and try to regenerate it from self._api.

This comment has been minimized.

@markddavidoff

markddavidoff Oct 19, 2018
Author

Can you help me understand how _build_url is used pleae?

For the Status endpoint which looks like /repos/:owner/:repo/statuses/:ref, I need the base url /repos/:owner/:repo/ and the ref which i can get from the Head.sha. However, I am unsure how to get that base url within the PullRequest context as self._api there looks like https://api.github.com/repos/octocat/Hello-World/pulls/1347.

I don't see a place where urls are dissected to get a different 'base_url'. This would be useful for #897 which faces the same issue.

This comment has been minimized.

@sigmavirus24

sigmavirus24 Oct 19, 2018
Owner

So you could do

self.repository._api

To get the base url you need, so then you would construct the call like so:

self._build_url('statuses', self.head.sha, base_url=self.repository._api)

tl;dr, _build_url takes positional args as parts of the path to be added and base_url is an optional keyword argument that defaults to https://api.github.com unless specified otherwise.

This comment has been minimized.

@markddavidoff

markddavidoff Oct 19, 2018
Author

Thanks for the explanation. I mostly wasn't sure on how to get the base url in this case, so thanks I can see that working.

It builds the repo url from the PullDestination login and name fields using ShortRepository. I think it would be self.repository.respository._api though right (PullRequest.PullDestination.ShortRespository._api)?

It seems roundabout but if we can't always trust the returned URL as you say, then this makes sense.

TODO: build url as in the second example above

This comment has been minimized.

@sigmavirus24

sigmavirus24 Oct 20, 2018
Owner

It builds the repo url from the PullDestination login and name fields using ShortRepository. I think it would be self.repository.respository._api though right (PullRequest.PullDestination.ShortRespository._api)?

I was looking at PullDestination's docstring 🤦‍♂️ so yes, that sounds fine. I think, though, that it would be self.base.repository if and only if self.base is actually present, kind of like

self.repository = None

This comment has been minimized.

@markddavidoff

markddavidoff Oct 22, 2018
Author

Nope, you were right idk what i was looking at lol. my bad. I guess I'll return [] in the case there is no base, but I'm confused how that's a valid case?

@markddavidoff
Copy link
Author

@markddavidoff markddavidoff commented Oct 22, 2018

Changed the way the url is built, tests coming soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.