Allow can-i-deploy to return true when there is a missing verification between a consumer version/provider version if there is another successful verification that contains verifications for all the interactions in the pact

[canny]

https://pact.canny.io/admin/board/feature-requests/p/allow-can-i-deploy-to-return-true-when-there-is-a-missing-verification-between-a

[canny]

This issue has been linked to a Canny post: Allow can-i-deploy to return true when there is a missing verification between a consumer version/provider version if there is another successful verification that contains verifications for all the interactions in the pact 🎉

[YOU54F]

Tim Jones - February 17, 2021

Oooh! I like this

[YOU54F]

Beth - February 17, 2021

eg.

• Pact A contains interaction a, b
• Pact B contains interactions a, b, c
• Consumer v1 publishes pact A, Provider v1 verifies it successfully.
• Consumer v2 publishes pact B, Provider v2 verifies it successfully.

Currently, matrix would look like:

• C1 / P1 success=true
• C2 / P2 success=true
• C1 / P2 success=??? (never verified, but we know that because Pact A was successfully verified by P2, then P1 must also be valid).

Question - is this useful? Or does it never really come up in practice? Need to do some further thinking about it.

[YOU54F]

Matt Fellows - February 17, 2021

I can see at least one potential use - a provider "self-verification". If it could write a Pact test for itself with all of its defined behaviour, any new consumer coming on board would automatically be compatible if it only used a subset of that contract. Very useful in the retrofitting use case, and helps get around the chicken-egg problem when first adding a consumer contract.

[YOU54F]

Matt Fellows - February 17, 2021

Related to this, although it's a separate request I think, is being able to collapse contracts at the point of verification. As it works today, in the Pacts for verification API, you are returned multiple contracts to verify. In many cases, there may be overlap (e.g. master and prod will likely overlap significantly for a given consumer). Collapsing the contracts into only the different interactions could speed things up.
I think we tested this though, and from memory, it didn't lead to a big performance improvement. But worth remembering.

[YOU54F]

Matt Fellows - February 17, 2021

Related to this, although it's a separate request I think, is being able to collapse contracts at the point of verification. As it works today, in the Pacts for verification API, you are returned multiple contracts to verify. In many cases, there may be overlap (e.g. master and prod will likely overlap significantly for a given consumer). Collapsing the contracts into only the different interactions could speed things up.
I think we tested this though, and from memory, it didn't lead to a big performance improvement. But worth remembering.

Beth - February 17, 2021

Matt Fellows: Ah yes. I did the stats on this and the numbers said, there were a small number of users for whom it would make a big difference, and a large number of users for whom it would make a small/medium difference.

4 likes