Hi, I originally asked this question in the wrong ...
# pactflow
k
Hi, I originally asked this question in the wrong channel: https://pact-foundation.slack.com/archives/C9VPNUJR2/p1687958938502709 I am curious if anyone would like to share an example of how the compatibility matrix of consumer and provider versions looks like for them? Were worried that even when you only have a few versions of a consumer and provider, that when you compare every consumer version to every provider version, that the compatibility matrix is going to explode. Were still in the early stages of working with contract testing and pactflow, and maybe were worried about something that isnt even a problem.
m
Yeah, it’s not really a problem. The current UI doesn’t help (and there is a project going on at the moment that we think will improve this DX significantly)
The retention rules will remove some of the old data, but potentially hundreds of redundant (i.e. outdated) pacts will be about that aren’t very useful.
We’d like to be able to setup some integrations with tools like GitHub, so that when a branch is merged/deleted etc., related contracts are also removed. You could look to set it up yourself
t
In practice you don’t need to worry about the size of the matrix, because the relevant information will be at the top.
It would matter if you were deploying versions at random from all history, but almost always people deploy recent versions.
For the same reason, you don’t need to verify all contracts from all time. Usually you do something like
dev
,
test
,
prod
,
<all others less than X days old>
.
Bonus subtlety - the pact broker thinks about contracts, which is different to consumer versions. Most consumer versions have a contract that is the same as a previous one.
eg, if there are no changes to the consumer contract between
dev
,
test
,
prod
(and you select all of those at verification time), you’ll only get one contract to verify.
m
Exactly, well put
The matrix view in the Pact Broker/PactFlow is a bit of a bum-steer - who wants to see a wall of entries. It’s not that relevant, most of the time, you’re interested in the question “what is this version of my app compatible with?” or “can I deploy this version of the app to <env>“.