Hi everyone! We're setting up automation with a Pa...
# pact-broker
а
Hi everyone! We're setting up automation with a Pact Broker. Let me share an issue we encountered. We have one consumer that interacts with five providers. For full automation, we need to use webhooks from the Pact Broker. However, for each branch, we need to create separate hooks for every provider. How can we get a list of providers that will be involved in the tests for the given consumer's changes, or how can we retrieve a list of all providers for a specific consumer?
m
However, for each branch, we need to create separate hooks for every provider.
Is that due to some CI limitation or something?
There’s a bunch of ways to navigate to the resources you might need, check out https://smartbear.portal.swaggerhub.com/pactflow/default/getting-started (some APIs are PactFlow only, but probably you can work out which ones)
Also, another tip is to add the
--verbose
flag to the CLI so you can see what calls it makes
а
The only issue is that we don't know when running the tests which webhooks need to be created and which don't.
s
If you're using open source pact-broker, there's a hal browser in the UI which documents the API pretty well. You can use it to retrieve all sorts of info. However you might not necessarily need to know providers ahead of time. In our use case due to CI system limitations we couldn't trigger build jobs directly from pact broker, so we built a very simple intermediate service that receives a webhook from the broker with all possible parameters in the request body and then in the intermediate service we can trigger the necessary CI jobs based on parameters received from the broker.
m
The only issue is that we don’t know when running the tests which webhooks need to be created and which don’t.
It sounds like there is a misunderstanding here. The simplest approach in most cases, is for a provider to setup a webhook without specifying which consumer triggers it. In this case, any consumer publishing a new contract that needs verifying, will trigger the provider’s build. This means consumers don’t need to know implementation details of how to trigger provider builds