Bug: Issues.ListByRepo Repository field is always nil

[erezrokah]

go-github/github/issues.go

Line 231 in 807d5cf

func (s *IssuesService) ListByRepo(ctx context.Context, owner string, repo string, opts *IssueListByRepoOptions) ([]*Issue, *Response, error) {

returns an Issue struct with a Repository field but it's always nil.

Looks like that's expected based on GitHub docs https://docs.github.com/rest/issues/issues#list-repository-issues

Doing gh api repos/google/go-github/issues doesn't return repository as well

[gmlewis]

It sounds to me like you are saying that the GitHub v3 API should return a repo with the endpoint.

However, this repo is a Go client library to the GitHub v3 API, and not the official v3 API itself.

Therefore, this bug report is in the wrong place and needs to be submitted to the official GitHub tech support team.

I'm going to go ahead and close this bug report, but feel free to refer to it when contacting the GitHub tech support team.

[erezrokah]

Hi 👋 thanks for the reply. Sorry for not being clear, I'm saying it should not return the repository based on the rest API schema from the GitHub documentation. So I believe the Go struct should not include that field.

[gmlewis]

Hi 👋 thanks for the reply. Sorry for not being clear, I'm saying it should not return the repository based on the rest API schema from the GitHub documentation. So I believe the Go struct should not include that field.

Oh! Gotcha. Now I understand. Sorry for being a bit slow.

It turns out in this repo that we reuse a great number of structs when they are mostly similar so that we don't have to define custom structs for every possible use case. As a result, we only remove fields when we are 100% confident that a field is not used elsewhere.

Feel free to open up a PR if you believe that is the case in this instance. I'll re-open the issue so that you or someone else can confirm or deny that the field is not used anywhere else and can indeed be removed as suggested.

[erezrokah]

It turns out in this repo that we reuse a great number of structs when they are mostly similar so that we don't have to define custom structs for every possible use case

👍 I believe we noticed this also for Repositories.ListByOrg and CustomProperties (only available on Get repo and not List).

Are you open to using the Open API schema to generate the structs per API endpoint?
I think it would be quite hard to manually flush out all the differences.
I'm not saying we should switch everything in one go, but maybe try to see what it gives in regards with the diff from the current code.

[gmlewis]

That sounds like an interesting proposal, and I'm not yet ready to commit to it, but would love to see some experimental results first if you are willing to put something together in order to see what it really looks like.

If it is too disruptive for current users of this repo, then we probably will pass.
But if it appears to be really useful and beneficial, then we can take the next step(s).