Cache Provider Contract on Pact Broker
Amit Dash
The use case for a cached provider contract is when a consumer has not been tested against a version of a provider before.
This will speed up the verification of new consumer versions against existing provider versions, as the consumers don't have to wait long for the provider pipelines to generate contracts, esp for the provider versions which have been already been a part of some verification before in older builds.
With the cache feature in place, the consumer triggered provider pipeline can first call a broker API (with required provider version / tag) to download the cached provider contract (if exists) and do the verification. If the cache doesn't exist then the pipeline will continue as usual with checking out the relevant commit, generating the contract, doing the verification and finally uploading both the contract and the verification result to the broker for the relevant provider version / tag.
I had a discussion on this with Matt Fellows on Slack, link to the conversion below:
Joel Whalen
Being able to see the actual requests/responses during verification would help with debugging the verification process immensely. Honestly don't even need a cache of the local pact files for this; if you could expose a callback hook for the request and response objects that could be logged to console in a callback in the
verifyPacts()
method that would work perfectly too.
Matt Fellows
I just got off the phone with a customer now who was asking for something this feature probably helps with.
Another interesting side effect of this feature would be that the actual provider response could be stored alongside the verification results which could be very useful for debugging (e.g. for showing in the verification results page). They indicated sometimes the output in CI tools makes this hard to see amongst the log output, and sometimes isn't shown unless debug or verbose mode is enabled (which you usually don't want to enable).
Beth
Just working through in my head how this could work. I think, from reading the conversation Amit, you suggested that the full response for each request be stored for future use. Then, if the contract changed, the stored response could be used to verify the pact, rather than having to run the verification tests. Not having to wait for the tests to run would definitely improve the workflow.
If my understanding of this feature is correct, I can see one way in which this approach would work, and some ways in which it wouldn't.
If the only change to the contract was that an existing interaction was changed so that there were new expectations for pre-existing fields, then the cached responses would be fine.
If a change was made to a request or a provider state, those cached responses would be invalid.
Am I understanding your proposal correctly @Amit Dash?
Matt Fellows
Beth: That was also my understanding.
Amit Dash
Beth: Yes that sounds right.
Thanks for confirming Matt Fellows