Pollable endpoint for webhookless workflow #468
Replies: 1 comment
-
If I understand the use cases correctly, this would be an alternative to this webhookless flow. The two approaches to circumventing webhook executions from Pactflow would be:
The pros of (1) being that no state needs to be managed and it's all managed in a single pipeline. The downside is that it requires access to a providers build to check-out and run locally, which may not be possible. The pros of (2) being that it's only job is to execute builds, and therefore doesn't need to have any specific knowledge of how to checkout a provider code base and run the build. The downside is that it would need to be a custom job runner somewhere, and would likely need to retain some state to determine what webhooks need executing. The other downside is that the management of (e.g. retries, reporting and visibility) webhooks is now a responsibility of the user, not Pactflow/Pact Broker. |
Beta Was this translation helpful? Give feedback.
-
Context
See https://pact.canny.io/feature-requests/p/support-a-polling-endpoint-for-a-webhookless-workflow
Some organisations do not allow connectivity to their CI systems from the Pact Broker for security reasons, which means webhooks can't be used to trigger a provider build when a pact changes.
For these situations, add an endpoint that can be polled by the CI system itself to trigger the required builds.
Potential design
Instead of creating a "triggered webhook" for each event, create an event log in a database table, with a UUID. Each event will have all the templated parameters that are available to a normal webhook.
The CI system (or some trusted intermediary) would poll the endpoint to determine which builds needed to be triggered.
Design decisions
Can the CI system (or what ever process is calling the endpoint) preserve state?
If it can, then it just has to pass in the "last processed UUID" each time, and the Broker can remain stateless.
If it can't keep state, it would need to let the Broker know which events it had processed, so that the broker could return only unprocessed events next time. If there were multiple CI systems running, this might get confusing though.
Do we need to make this configurable?
Apart from "on"/"off", do we need to configure events to any greater granularity? I'm assuming that if anyone needs this endpoint, the entire organisation needs it, rather than just a subset of pacticipants/events.
Clean up
This table could get big fast, and so would need to be cleaned up at some stage. Do we link the events to their pacts/versions so that when the versions get cleaned, the events get cleaned too, or do we have a separate cleanup config.
Potential endpoint format
Beta Was this translation helpful? Give feedback.
All reactions