ostrolucky
commented
5 years ago Reply:
Hey there Gabriel,
Thanks for writing in and I hope you are having a great day where you are.
We can certainly pass this on as a feature request to the product team for you.
However given the description of your use case here, I'd certainly consider pivoting your implementation on our Webhooks feature:
Webhooks allow you to subscribe to certain events happening in the system, such as the ReleaseEvent: https://developer.github.com/webhooks/#events
When one of those events happen, the webhook is triggered and sends a notification to the subscriber containing a payload describing the event (a POST request to a publicly accessible endpoint).
You can then process this event as, and when, they occur. This is far closer to real time than attempting to poll the API for data. Polling is wasteful, since you have no way of determining when a new event might occur, and therefore when new data might be available whereas with webhooks, no interaction happens between the user and server until new data is available.
If you have a lot of events occurring, polling for these again doesn't scale well via the API, and you would probably end up draining your API rate limit really quickly. Whereas webhooks being triggered as part of the event, aren't constricted by rate limits (as it is less expensive in terms of computation for us to trigger this at event time, than it is to process a GET request and query against data).
If we consider the ReleaseEvent: https://developer.github.com/v3/activity/events/types/#releaseevent, these are triggered when a release is created, and published - providing a sender key/value in the payload representing the user that published this.
This provides you with the information on who published, at the point of publishing, without having to poll for this data.
I hope this helps! Keep an eye on our changelog for updates: https://developer.github.com/changes/
Thanks Matt Barber
👾 Find answers to common questions and learn with other GitHub users in our new GitHub Community Forum 👾
My reply:
Hey,
we indeed do use webhook, but it’s just for triggering the deploy. Using it also as a source of data to log would require us to build infrastructure for that :/ So far we were relying on your /releases endpoint for that. Please pass it to your engineers. Thank you very much :)
Gabriel
Dear Github,
FIrst things first, I must say I love your product. But you must get tons of e-mails like this, so let me cut straight to the chase:
We use https://github.com/apps/release-drafter which automatically creates release drafts. Now, we realized there is a problem with this strategy: Since draft is created by bot account and it’s only published by us, there is no way how to find out who published the release, only who created the draft - and that’s always the bot. Can you please add this information? This is unfortunately missing from your API too, so there really seems to be absolutely no way to find out this information. This information missing is very unfortunate, because it’s common to tie tag creation with continuous deployment, so this effectively means we cannot find out who deployed changes.
To be more technical, since sometimes people understand that approach better, what I ask ask for is to have at least something like
published_byin responses for for these endpoints https://developer.github.com/v3/repos/releases/If you don’t mind, I will also create issue for this e-mail thread at https://github.com/isaacs/github
Thank you. Gabriel Ostrolucky