Hi In my org we had done an alignment to adopt pac...
# general
p
Hi In my org we had done an alignment to adopt pact as a contract testing framework, which will help us write the pact tests which then eventually help us eliminate any contract breakage between services in production or release branches. Now I have multiple questions regarding consumer and provider side of things: Consumer: 1. In the consumer application, should i publish pacts for each version (version being a commit id when the squashed commit merges in any branch) and branch (develop, release branch 1, release branch 2) OR should I only publish when the pact changes with the version and branch name? 2. When writing pacts in the consume side, what naming convention should we follow for consumer and provider. If I choose to use consumer name as the actual service name, it will be too generic and all set of interactions for that consumer service and the provider service will all go into that pacticipant. Also will I get this visibility of which interaction’s verification has failed in the pact broker OSS version ? Provider: 1. Should a provider write pact test without the consumer actually implementing their pact tests ? If yes, then lets say the provider writes the pact test for their service and in future the consumer also writes the pact test, uploads the pact to pact broker and for some reason the provider pact tests (verification starts failing) starts failing in this case. Should we stop the provider PRs in this case ? 2. In our current provider verification, we have passed consumer version selectors as “matchingBranch:true” since all our services in the org follow the same branch name convention and the release branches are cut at the same time, which then means that the provider will only pull in the pact for that particular branch? Is this the latest pact from that branch (latest version of consumer indirectly) ?
r
> 1. In the consumer application, should i publish pacts for each version (version being a commit id when the squashed commit merges in any branch) and branch (develop, release branch 1, release branch 2) OR should I only publish when the pact changes with the version and branch name? You can publish a consumer pact for each commit. If the pact is the same as the previous version, no provider revalidation is needed > When writing pacts in the consume side, what naming convention should we follow for consumer and provider. Hard to say. We typically do the name of the application (the thing that we deploy). But if you say that would be too generic then I'm not sure what to recommend
thankyou 1
1. Should a provider write pact test without the consumer actually implementing their pact tests ? If yes, then lets say the provider writes the pact test for their service and in future the consumer also writes the pact test, uploads the pact to pact broker and for some reason the provider pact tests (verification starts failing) starts failing in this case. Should we stop the provider PRs in this case ?
You cannot really know that the provider tests work if there is no consumer test. So usually it make sense to create the two in combination. Still it can happen that a consumer test is merged where the provider validation is broken. We use the
can-i-merge
feature to prevent this from happening, but you can also use the "pending pacts" feature, which makes the provider test success (but still report the failure to the broker) so ti does not break any pipelines
Is this the latest pact from that branch
Yes, branch selectors select that latest version on that branch
p
@Ruud Welling thanks a lot for the reply!! Answers a lot of my questions
y
Thanks @Ruud Welling, great answers
r
Happy to help