Comments (5)
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.
from go-github.
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.
from go-github.
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.
from go-github.
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.
from go-github.
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).
from go-github.
Related Issues (20)
- List[Organization]Runners does not support all query parameters
- Merge Queues break repository ruleset unmarshaling HOT 8
- Getting the metadata of an issue in github project planning board HOT 1
- Changing custom properties HOT 5
- Update deprecated endpoints in github/action_variables.go HOT 4
- `omitempty` tag on `InstallationAccessTokenOptions.Repositories` masking functionality of GitHub API HOT 11
- `NewTeam` missing `notification_setting` field HOT 1
- feat: Add an option to wait for primary rate limit reset and retry instead of erroring out HOT 7
- Username is required when using fine-grained vs classic PAT (personal access token) for PlainClone operation
- LIst of issue comments do not collect the comment which was added during the creation of the PR. HOT 6
- Use enums for the action field in GitHub Webhooks HOT 4
- Can't remove repository ruleset's every Bypass Actors because of serialization issue HOT 4
- Support new REST API endpoint that evaluates if private vulnerability reporting is enabled HOT 4
- Webhook MemberEvent Type is Missing Changes Object
- `ListRunnersOption` change omits consideration of Enterprise Runner HOT 4
- Add support for CommitID, InReplyTo, and SubjectType to DraftReviewComment HOT 1
- Support for merge queues. HOT 3
- Bug: GetArchiveLink returns a status code 200, not 302, when link is requested with an installation token rather than personal/bearer token HOT 3
- WorkflowRun struct does not include `path` property HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-github.