Open dshack opened 10 years ago
Looking at webscript, seems like we'd need to utilize the counter functionality.
So every time a webhook is sent for an incident when the state is triggered/acknowledged/resolved it would need to update the appropriate counter and then update the correct widget via the Dashing API.
So imagine this lifecycle:
With this type of setup I think the pagerduty_incidents.rb job could just go away.
I will say that I think there some actions which are best suited for polling, such at the daily/weekly/monthly queries, that's what the incidents per time api is for.
I like where this is headed though. Also, looks like I should try out some Lua :)
The only issue there is that you have to trust the webscripts.io script to maintain the right count. What I'm thinking is that jobs are normally scheduled for a long interval (say, 5m), but any time there's an inbound webhook, it runs the incidents.rb job right then. If webhooks fail for some reason, the widgets will still get the data through polling.
Just added a sample of this to pagerdashing.herokuapp.com/combo. The widget code is:
<li data-row="1" data-col="1" data-sizex="1" data-sizey="1">
<div data-id="incident_desc" data-view="Text"></div>
</li>
I do want to figure out how to conditionally make the text smaller for longer descriptions.
Pretty much, what I want to do is:
Use this to translate a PD webhook into a dashing event: https://gist.github.com/dshack/2446ffdf9eb5a17f6c21
Then have that run the pagerduty_incidents.rb job, so that it's not polling until/unless there's an incoming incident.