webhook: Filter check_(suite|run) completed events #988
Conversation
Only listen to created and requested event types. - created: when the check is created by github for some work to do - rerequested: when the user hits the retry button - requested_action: (check run only) when the user hits another button on the check (corresponds to the `actions` field - technically not applicable for the webhook right now, but there's no harm in including it) Mainly, this filters out completed events so we don't trigger a webhook check after we just finished updating a check, causing an infinite loop.
|
Moving to draft - there's more work needed here in order to try and better filter out the specific workflow events. What's likely happening here is we're mixing up general repo and app checks with checks specifically for the webhook validation. But because we also encourage people to use this app to create additional checks, we need to be more careful about which checks we'll re-trigger on. There's a subtle weakness here in that users of the octo-sts token can overwrite the checks that the webhook produces since they use the same identity. There isn't really additional exposure here though, since the webhook only tells you whether the policy is well-formed so you don't submit a busted config and is not intended to be a check for what policies are allowed - i.e. the failure mode is you might submit a broken config that then won't issue tokens. 🤷 |
|
@wlynch Thanks for this, in the case where the Hope that makes sense, it's been a while since I looked at this so I may be crossing some wires (apologies if thats the case). |
Only listen to created and requested event types.
actionsfield - technically not applicable for the webhook right now, but there's no harm in including it)Mainly, this filters out completed events so we don't trigger a webhook check after we just finished updating a check, causing an infinite loop.