PagerDuty's Events API v2 (docs) allows sending two types of events: standard events (docs) and change events (docs). They both use a routing/integration key, while PagerDuty's REST API v2 uses an API key.
Currently, the official PagerDuty step provided by Codefresh implements the REST API for the PAGERDUTY_ALERT_TYPE of incident, and only the change events subset of the Events API for the PAGERDUTY_ALERT_TYPE of change_event. This means that users of the Events API can only send change events, but not trigger incidents by sending a normal event.
The PagerDuty step should support the entire Events API instead of just a subset. This can be done without breaking backwards compatibility. The step uses PagerDuty's pdpyras client to send requests, and implementation is as simple as importing its existing EventsAPISession.
Personally, I've had to implement my own custom PagerDuty step to create alerts from Codefresh, which isn't ideal.
PagerDuty's Events API v2 (docs) allows sending two types of events: standard events (docs) and change events (docs). They both use a routing/integration key, while PagerDuty's REST API v2 uses an API key.
Currently, the official PagerDuty step provided by Codefresh implements the REST API for the
PAGERDUTY_ALERT_TYPE
ofincident
, and only the change events subset of the Events API for thePAGERDUTY_ALERT_TYPE
ofchange_event
. This means that users of the Events API can only send change events, but not trigger incidents by sending a normal event.The PagerDuty step should support the entire Events API instead of just a subset. This can be done without breaking backwards compatibility. The step uses PagerDuty's
pdpyras
client to send requests, and implementation is as simple as importing its existingEventsAPISession
.Personally, I've had to implement my own custom PagerDuty step to create alerts from Codefresh, which isn't ideal.