GitHub Community
consistency of 'repository.url' between event types #24448
-
|
Depending on which event you listen to, the attribute ‘repository.url’ is different:
“url”: “https://github.com/McFoggy/github-api-events”
“url”: “https://api.github.com/repos/McFoggy/github-api-events”, If we look at the repository payload in the API v3 documentation (https://developer.github.com/v3/repos/#response) it should point to the API URL. Is it for historical reasons or is it a bug? Is it consistent between github.com & private on premise github installations? Are there other known inconsistencies? It is important to me because I am developping software & plugins that target both type of installations. In both payload below ‘repository.url’ attributes are differents: Push event payload Create & other events payload I collected complete payloads of webhooks in an example project: https://github.com/McFoggy/github-api-events/blob/master/README.md |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments
-
|
PING Does someone know how the on premise enterprise edition reacts in this case? Is the payload the same as the github.com API or does it conform to the documentation? Thank for any help that could be provided. |
Beta Was this translation helpful? Give feedback.
-
|
It appears to be a bug but I haven’t been able to confirm that with the development team at this time. I don’t know if there are any other inconsistencies, no. I can’t promise if or when this would be fixed, unfortunately. My recommendation, at least for now, would be to use the documented v3 REST API URLs for retrieving information rather than relying on the API URLs in the event objects themselves. I hope that helps! |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that’s what I ended up doing as well. But a proper fix would be great to have :slight_smile: |
Beta Was this translation helpful? Give feedback.
-
But when you have a webservice/application/integration that listens to a webhook event ; in order to call back the server which fired the webhook you have to use the ‘repository.url’ field which contains a wrong value 😉 I’ll implement some logic (receiver side of the webhook) to detect which field contains the good value. |
Beta Was this translation helpful? Give feedback.
-
|
@lee-dohm any news from the dev team? |
Beta Was this translation helpful? Give feedback.
-
|
Nope, my recommendation still stands. Use the documented endpoints. Or you could convert to using the GraphQL v4 API which only has one endpoint to use for everything. |
Beta Was this translation helpful? Give feedback.
But when you have a webservice/application/integration that listens to a webhook event ; in order to call back the server which fired the webhook you have to use the ‘repository.url’ field which contains a wrong value 😉
I’ll implement some logic (receiver side of the webhook) to detect which field contains the good value.