You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To make the workflow metrics integration more reliable and to avoid rate limiting because of the amount of required api calls we should rebuild the workflow metrics based on webhooks sent by GitHub. The webhook will receive all required information by GitHub and will store the information within BoltDB which makes the service sadly a stateful service.
The text was updated successfully, but these errors were encountered:
I was wondering why you chose to use webhooks rather than API calls and i came across this issue.
Do you have any feedback to give on this choice ?
is it reliable and stable as you were expecting ?
no more problem with github api rates with your exporter ?
Also i wanted to export deployment statuses, have you already thought about that ? afaik it would not be possible to use any hook for that, do you think it would make us reaching the limit as well ?
We have introduced this changed behavior for the workflow metrics to avoid running into api rate limit errors which works out pretty well. You are still able to run into api rate limit errors for the other metrics, but you just need to use a proper paging size and do not too often scrape the exporter to avoid that.
I haven't checked the API for deployments, but since those could also be a lot I would suggest to extend the webhook receiver and use this instead.
To make the workflow metrics integration more reliable and to avoid rate limiting because of the amount of required api calls we should rebuild the workflow metrics based on webhooks sent by GitHub. The webhook will receive all required information by GitHub and will store the information within BoltDB which makes the service sadly a stateful service.
The text was updated successfully, but these errors were encountered: