Hi again :slightly_smiling_face: What would be the...
# pact-jvm
r
Hi again 🙂 What would be the right way to go about using
can-i-deploy
for a provider, who has no consumers and therefore no verifications were made yet? I receive the
No pacts or verifications have been published for service-A
error. If there are no instances of
service-A
in the pact-matrix, shouldn't it be as if it is safe to deploy? Important to point out that the verification tests do pass, as there is no pacts to verify. Thanks :)
y
hey, technically consumer driven contract testing with Pact doesn’t support using can-i-deploy with no registered consumers. therefore in order for the check to pass, the consumer must have at least one successful verification for the version you wish to deploy
ie, it doesn’t make sense to call can-i-deploy for a provider who has not verified any contracts
you can dry run flags, to skip the can-i-deploy check, or in this case, if your provided is deployed, mark that version as deployed in an environment. When a consumer comes along and registers a contract test, it should verify against the deployed version of the provider and the HEAD of the defined main branch. at that point, if the contract is successfully verified the consumer would be able to proceed, otherwise it would be a communication point with the provider to ascertain which side the misunderstanding lays, and work a path forward
Bi-Directional contracts via PactFlow support an alternative flow, whereby a provider can publish a contract advertising their capabilities (currently described in an OpenAPI definition), the user self tests their implementation against the OpenAPI definition, and if successful, can use the can-i-deploy tool, and then record a deployment. As in your case, no verifications within Pact have taken place with the provider, Pact can offer no guarantees at can-i-deploy time
r
message has been deleted
@Yousaf Nabi (pactflow.io)
ie, it doesn't make sense to call can-i-deploy for a provider who has not verified any contracts
As a platform engineer, it makes perfect sense 🙂 I would like to provide my company's developers the best UX possible, a part of that is providing a whole solution out of the box. If there are no instances of a service in the Pact Matrix, I would expect the
can-i-deploy
call to succeed, sense there is nothing blocking me from recording a new deployment (no contract has been broken). Instead of having it succeed in such case as stated above, I would have to ask them to do a manual
record-deployment
for each new service, and for a company that is transitioning from a monolith to microservices - this will occur many times.
m
👉 the answer you are looking for is here: https://docs.pact.io/pact_nirvana/notes_1
y
So I believe Ran has added that Matt, which is why the provider exists but doesn’t return a valid can-i-deploy as there are no verifications associated with it
would a
--pass-if-no-consumers
flag or something similar work on a
can-i-deploy
rather than it being a default behaviour. The premise being that
can-i-deploy
offers guarantees about the compat of an application prior to deployment. As the Pact framework does nothing, in Consumer driven contract testing (with zero consumers), we have zero guarantee or basis to tell you your application is safe to deploy. At least that is my take on the current behaviour.
Personally from experience, this hasn’t been an issue for us, as we traditionally at the start of an applications lifecycle we might not opt in for being gated by can-i-deploy but rather using it as an additional check. As confidence builds up, it can be brought into the estate as a first class tool that does indeed gate your deployments. Also being aware of the break glass mechanisms, for if you need to skip can-i-deploy is useful too, for those times you just need to get something out the door pronto. Also as consumer driven contract testing uses provider states and matchers, the provider tests aren’t usually written in isolation from the consumers. Having the boilerplate their when you spin up a new provider service is good, but hooking it up with your pipelines, prior to having a consumer doesn’t seem sensible. It’s like trying to automate the conversation away
r
--pass-if-no-consumers
would absolutely work. I get what you are saying, but if you look at it from an infrastructural point of view, meaning the platform is my product and the developers are my clients - I need to provide a fluent way for their CI to pass for each service, regardless of their rule (provider/consumer). Every new provider needs to perform a
record-deployment
for the first time, that does not mean that the provider does not have any consumers. It only means that it does not have a deployed version in which the consumers could push that pacts and verify against. The notion that a provider must have consumers that have already published pacts is a bit problematic.. I guess I would have to call
list-pacticipants
and check whether the service is listed or not. In case it is not I would need to use the
can-i-deploy dry-run
m
So I believe Ran has added that Matt, which is why the provider exists but doesn’t return a valid can-i-deploy as there are no verifications associated with it
It should work without that. You need to both create the application and create an application version
👍 1