https://pact.io logo
Join Slack
Powered by
Pipelines for both our products (API & Dashboa...
# pactflow
e
Pipelines for both our products (API & Dashboard) are now fully integrated with Pactflow bi-directional contract testing 🚀 I will continue keeping an eye on channels here for updates & provide feedback as it arrives 🙂
🙌 1
• OAS publishing • Consumer Contract generation with 
openapi-backend
+ 
msw
+ 
pact-msw-adapter
• 
can-i-deploy
on pre-merge checks and pre-deploy jobs for every env for both products • 
record-deployment
on post-deploy jobs for every env for both products Thank you for the support we have received to take it online!
🎉 1
u
❤️
we're almost there with a very similar setup
quick question: which pact selectors do you use for verifying contracts, e.g. from the provider side of things?
e
great question from the Advanced Topics category @Ulises Cervino, which I haven't touched yet 😄 what am I missing out on?
quick scan of the docs suggest that this allows to limit which provider<>consumer contracts are verified? looks like a good way to reduce the load on Pactflow / potentially speed up verification / reduce the amount of lines in the Matrix? Where does this config live?
u
right, yes
you can do this in a couple of ways, but the only way I managed to get it working was with a 
@Selector
or whatever in pact-jvm
and the idea is that, for instance, a provider only tries to verify consumer pacts for versions that have been rolled out/released and not for absolutely every branch
I think the default behaviour is only verify pacts for the 
master
branch, which might not be what you want at the beginning actually
e
would be great for someone from Pact team to elaborate on this 🙏 I currently only care about verifying OAS against Consumer Contract that is recorded to be deployed in 
dev/test/staging/prod
Same goes for verifying Consumer Contract against OAS recorded to be deployed in 
dev/test/staging/prod
So 
main
branch for both
m
In this workflow you don't specify any selectors as there is no provider verification, unlike in regular Pact. Pactflow automatically pre verifies several consumer versions against the uploaded provider contract (this is what you see on the matrix page) and additionally it will dynamically compare the necessary versions during can I deploy.
If you think about it it makes sense. The provider publishes what it can do, the consumer publishes what it needs and when it comes time to deploy (or simply run can-i-deploy) it will tell you if they're compatible. This is what makes the flow much more simple and decoupled
👍 1
By default I believe it compares against main branches of consumers and deployed/released versions
u
this is something I am actually wondering: I've specified no consumer selectors, hoping that my provider tests would try and verify all pacts, however I must ask: would this verify older pacts (for the same consumer/version/environment combination)? I suspect not? If I only specify the consumer in my provider test, will it try to verify all version/branch/environment pacts?
(we're running pactflow internally)
m
verify all pacts
when you say “all” what is your definition? In the case of some customers, that could literally be hundreds of thousands of pacts. I should also - I’m assuming you’re asking about regular Pact, and not BDCT right?
u
caveat: I'm still trying to figure things out. Ref regular Pact vs. BDCT, I don't know the actual differences. We have consumer tests (written by other teams) and provider tests (written by us). In principle, when I verify contracts (provider tests) I'd like to aim for coverage (until it becomes a problem). That's what I mean by "all": if there's a branch 
B
of consumer 
C
that published a contract, when I run my provider tests I'd like to pick up the latest version of it. This is for all branches and consumers.
m
cool. Have you run the CI/CD workshop before? That’s worth doing, because I think it will cover what you are wanting to do
(see howtolearn 👇 )
s
Here are a number of useful hands-on labs that teach all of the key concepts: https://docs.pactflow.io/docs/workshops and https://docs.pact.io/implementation_guides/workshops
u
let me double-check, but worth asking: is this the cycle in which consumers publish pacts and via webhooks verifications are triggered, providers verify contracts on pushes to branches, and eventually it all converges on consumers/providers all checking 
can-i-deploy
before rolling out? (and when rolling out recording the versions deployed)
m
yep pretty much!
It talks about how to map the tooling onto your CI/CD processes basically, and answers your question how to validate “all pacts”
u
I should watch it then, for the "validate all pacts" bit (the rest of the pipelining is in place)
now, quick question: is the "validate all pacts" to do with the consumer pact selectors?
and actually, regarding selectors, maybe I missed it: are these the recommended guidelines still https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors#recommended ?
m
It’s the combination of selectors, wip and pending pacts
TL;DR - wip is probably what you need to ensure you validate all the current work in progress branches/features, alongside the important ones you specify in selectors
u
right, at first I thought checking only deployed/released is what I want, but then I thought that that might be premature optimisation, which made me think "verify ALL pacts", including wip
as long as we're vigilant and aware that if wip fails that's fine™, then it should be all right?
3 Views
Open in Slack
PreviousNext
Powered by