Anyone using webhookless workflows out in the wild...
# general
y
Anyone using webhookless workflows out in the wild?
t
I have never used the webhooks. AMA
thankyou 1
y
1. Why are you awake night 🦉 😅 (jk - pot calling the kettle black) 2. When a consumer contract changes, assuming you are using a regular CDCT flow, where you use Pact to verify your provider, how are you triggering the provider build to return verification results
oh 11pm that isn't too bad - timezones shifting everywhere at the moment
Does anyone, or have you used providers on a cron or something similar to pick up contracts requiring verification (via include work in progress pacts) or similar?
👀 1
a
I've used webhookless before with Teamcity where the provider has a snapshot and artifact dependency on the consumer, so each time a new consumer version is built the provider automatically runs verification also
t
If all services are under active development, you don’t need to trigger verification, you can just wait for a new build to happen. If your contract isn’t changing, you don’t need to trigger verification either. If the contract is changing, but the provider isn’t under active development (unlikely, but does happen), other options I have used: • you can tie the builds together (I think this was also teamcity, but I don’t remember). This wouldn’t scale well to hundreds of services • Manual build kickoff (doesn’t scale well at all) • Schedule the verification to run every X minutes (kind of a hack) Most of the time I’ve been working in the situation where active development is happening in both services, so it’s not really a problem to not use the webhooks. Clearly the webhooks would be better than all of the above, as you’d be able to do immediate deploy checks or whatever. But most of the time I don’t think you need them
the key point is - you only need to kick off the provider verification if: • you are changing the contract, and • you want to try to deploy immediately You only need to do this with a webhook if the provider is not under active development. If the provider is not under active development, and is not compatible with the contract, the deploy check will fail anyway. So, the only case that matters is if the provider is already compatible with the new contract - say the development finished before the pact was published. I try to use contract tests in a TDD way, so usually the consumer team have published the contract before the provider team does the work. Which means we’d get no benefit from the webhooks. Which in turn means I have never got around to figuring out how they work - the benefit isn’t worth the investment. If I already knew how the webhooks worked, I’d use them every time, probably. I imagine they’re not difficult to set up.
This webhookless strategy has the advantage that it encourages consumer-driven API development, I suppose.