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
Matt Fellows
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
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.
Matt Fellows
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.
Beth
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.
Tim Jones
Oooh! I like this