Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache Provider Contract on Pact Broker #91

Open
canny bot opened this issue Jun 26, 2024 · 4 comments
Open

Cache Provider Contract on Pact Broker #91

canny bot opened this issue Jun 26, 2024 · 4 comments

Comments

@canny
Copy link

canny bot commented Jun 26, 2024

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:
https://pact-foundation.slack.com/archives/C5F4KFKR8/p1624080302205500

https://pact.canny.io/admin/board/feature-requests/p/cache-provider-contract-on-pact-broker

Copy link
Author

canny bot commented Jun 26, 2024

This issue has been linked to a Canny post: Cache Provider Contract on Pact Broker 🎉

@YOU54F
Copy link
Member

YOU54F commented Jun 27, 2024

Beth - June 20, 2021

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.

@YOU54F
Copy link
Member

YOU54F commented Jun 27, 2024

Matt Fellows - August 2, 2021

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).

1 like

@YOU54F
Copy link
Member

YOU54F commented Jun 27, 2024

Joel Whalen - Feb 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant