https://pact.io logo
Join Slack
Powered by
Hello, We are using <pactflow.io> in our company,...
# pactflow
a
Hello, We are using pactflow.io in our company, and I was wondering how could we implement a good consumer driven testing flow into our CI. My idea is that when we change or implement a route then we create and publish the Pact test (we have implemented this already) that is also verifies with the backend. And we could add PR checks on GitHub for the backend that wouldn't let code merge when the contract testing is not green. But you might have a better idea of how to integrate PactFlow into our CI and deployment process, it would be nice to hear. Hope its the right channel to ask?
y
Hey, Working through this workshop should help with the core concepts and recommended setup https://docs.pactflow.io/docs/workshops/ci-cd/
☝️ 1
a
Thank you I will check that!
@Yousaf Nabi (pactflow.io) I got stuck here:
is this the correct route described in the docs? In GitHub docs I found this:
y
The workflow in the example-provider repo, is configured for the repository_dispatch event https://github.com/pactflow/example-provider/blob/594529a11b188f55d6dc86d95355f8a9[…].github/workflows/contract_requiring_verification_published.yml You could use the one in your docs, for a 
workflow_dispatch
event, but would need to update your 
.github/workflows/contract_requiring_verification_published.yml
to match
a
Thanks for the quick reply! I'd rather stick to the guide then with your dispatch but it doesn't seem to work
I have the token like so
The build is OK
I have tried to remove the duplicate Access: access also from the header, not sure if its a typo or on purose, but same result
y
So this is it setup in our testdemo broker
thx for sharing screenshots
yeah that looks like a typo in the headers
Copy code
Content-Type: application/json
Accept: application/vnd.github.everest-preview+json
Authorization: Bearer ${user.githubToken}
duplicate Accept, will update the docs, not sure if that will solve your problem. You have got the gh token added in your secrets?
a
Thanks! Unfortunately fixing that doesn't solve the issue. I get the same error message. Yes I have added it there tried multiple times
OK now it worked, I started from scratch
y
sweet! wonder what that was, well anyway, thanks for noticing an issue in the docs, and I’ve pushed a change up for that now which is just deploying now so thank you
a
Cool! Thank you! I am not sure, because I did exactly the same just navigated away from the Webhook tab and went back and clicked on create a new one
The only difference I didn't add a description. Maybe some value was not updated for the test when I've changed it or something. Thank you! I will keep doing the workshop
OK so I have finished.. The WIP part was a bit heavy. It's nice, but a more realistic workflow for me would be to replace deployments with merging to a staging branch. Because at the last steps you have to notify the consumer maintainers that at that point in time its OK to merge their feature branch. I think in your example code the provider master and consumer master is always matching, but I can imagine a scenario where the feature branch of consumer matches the main branch of the provider but then the main branch of the provider doesn't match with the main branch of the consumer.
So ideally all this process that is related to the feature branch waiting for the provider to comply with the contract should be done on a staging branch
And the actual deployment should be a check between master-master Pact check?
It'd be great if when the main of provider passes the test with the feature branch of the consumer the consumer can-i-deploy would be re-run by a webhook or something like that
Does WIP means that the main branch of the consumer can be mismatched while the main branch of provider matches the feature branch of the consumer?
Open in Slack
PreviousNext
Powered by