https://pact.io logo
Join Slack
Powered by
:wave: <@U9UUY3CU9> should we expect the consumer ...
# general
b
👋 @Matt (pactflow.io / pact-js / pact-go) should we expect the consumer to be deployable if the provider has not implemented the business logic for an endpoint which has been declared in an OAS document?
m
No. Is this in the bi-directional contract testing flow?
👍 1
I’d expect to either a) not publish the OAS to Pactflow, or publish the OAS to Pactflow but b) fail the provider test (and send that failure notice to Pactflow)
b) would result in a compatible contract, but because the provider self-verification is failing, the 
can-i-deploy
check would fail, because the provider doesn’t implement the OAS (so it’s not trustworthy)
or put another way - would you want to deploy the consumer if the business logic of the provider wasn’t there, but the provider code was compatible with the spec?
(I wouldn’t)
b
Hi @Matt (pactflow.io / pact-js / pact-go) yes it's bi-directional
We've updated the OAS (by adding a new endpoint) and published it to PactFlow.
But the provider didn't have a test and implementation of that endpoint.
But the consumer was able to publish and it was compatible after writing an interaction and consumer test.
How can we b) fail the provider test (and send that failure notice to Pactflow)?
What can I do to not be able to deploy my consumer if the provider hasn't implemented the endpoint, but the provider has published an OAS which makes my consumer compatible?
I can see in PactFlow that... Your Provider Contract Is Not Compatible With The Provider Codebase. And I don't want to the consumer to be able to deploy. What would I have to do differently to make that happen?
y
Hi Bernard, Checks would be required on the provider sides ci workflow when using BDC, prior to uploading the OAS spec to Pactflow, these would ensure that an OAS published, is honourable by the provider codebase. The onus here, is on the providing team to ensure they have checks in place. You have the ability to upload your provider OAS specs on branches, and mark them as deployed when they reach a particular environment, which allows your provider to develop breaking features on a branch, and get validation feedback via can-i-deploy as to whether that contract would honour the consumers needs.
🙌 1
What can I do to not be able to deploy my consumer if the provider hasn't implemented the endpoint, but the provider has published an OAS which makes my consumer compatible?
provider verifies OAS spec against providing service prior to uploading pactflow contract. You are able to upload a result along with the provider verification which would give you feedback via the pactflow UI, that the provider codebase is not compatible with its OAS spec. Hope that helps @Bernard Baker
🙌 1
b
Thanks @Yousaf Nabi (pactflow.io) I'll look into that
m
Are you saying the consumer is passing 
can-i-deploy
in this case?
b
@Matt (pactflow.io / pact-js / pact-go) yes the Consumer was passing 
can-i-deploy
.
Hi @Matt (pactflow.io / pact-js / pact-go) and @Yousaf Nabi (pactflow.io) firstly thanks for getting back to me. I think your feedback has resolved our issues. We were missing a step in the Provider workflow where the OAS has to be verified against the local API. Before running tests and attempting to publish.
👍 1
y
Fabulous, pleased to help @Bernard Baker
Open in Slack
PreviousNext
Powered by