https://pact.io logo
Join Slack
Powered by
Hello, I'm running can-i-deploy for "*myservice*" ...
# pact-broker
a
Hello, I'm running can-i-deploy for "*myservice*" application by providing a application version which doesn't exist in pact-broker and it returns "*No*" as expected: 
pact-broker can-i-deploy --pacticipant=myservice --broker-base-url=<https://my.cool-pact-broker.com> --version=f7a284be9046416fad7a577bb52737af571dd6d1  --to-environment=prod
Computer says no ¯_(?)_/¯
No pacts or verifications have been published for version f7a284be9046416fad7a577bb52737af571dd6d1 of myservice
Then I'm running pact-broker create-or-update-version by providing that version: 
pact-broker create-or-update-version --pacticipant=myservice --broker-base-url=<https://my.cool-pact-broker.com> --version=f7a284be9046416fad7a577bb52737af571dd6d1
And after that I'm running pact-broker can-i-deploy again 
pact-broker can-i-deploy --pacticipant=myservice --broker-base-url<https://my.cool-pact-broker.com> --version=f7a284be9046416fad7a577bb52737af571dd6d1 --to-environment=prod
Computer says yes \o/
There are no missing dependencies
And it returns "*yes*" for all the environments for that particular version. Is this behavior expected?
m
Does it have any dependencies?
I think it’s expected, because if there are no dependencies, none of the dependencies can be broken, so from an integration point of view it’s safe
a
Hey @Matt (pactflow.io / pact-js / pact-go). Yes, it has. This microservice has multiple providers with published and validated contracts. In the CI flow we're building, we don't allow the pipeline to fail during the pact test stage and let can-i-deploy to control (to pass/fail) the pipeline. We run the create-or-update-version command to avoid other following Pact Broker commands failing due to a missing version in Pact Broker if the Pact test fails. But after the create-or-update-version command, can-i-deploy returns yes, although there are no published/verified pacts for this version, but there are existing dependencies for the previous versions in Pact Broker.
m
I think that’s probably the problem. That version doesn’t have any dependencies - other versions might and they aren’t deployable. @Beth (pactflow.io/Pact Broker/pact-ruby) can probably clarify for me, but logically that’s how I would think of it.
we don’t allow the pipeline to fail during the pact test stage and let can-i-deploy to control (to pass/fail) the pipeline
why? That’s like saying “if my unit tests fail, i’ll still deploy if my end-to-end tests pass”
a
don't quite agree, deployment shouldn't happen due to a failure in the "can-I-deploy" stage
why?
Reason to do it this way: Our release engineering team is currently not using webbooks for some reason and is triggering a pact verification pipeline based on GitLab dependencies on pact publishing stage. This approach avoids the failure of the pipeline at this stage for this type of contract testing pipeline configuration in case the downstream pact verification pipeline fails for any reason not related to the contract, but the published pact is not changed and previously successfully verified.
I think that’s probably the problem. That version doesn’t have any dependencies - other versions might and they aren’t deployable.
my understanding is that dependencies are more about the Pacticipant and not the specific version. If a version exists in Pact Broker but has not been verified, "can-I-deploy" should answer "NO" with the reason "not verified for that version".
b
my understanding is that dependencies are more about the Pacticipant and not the specific version
Incorrect
The dependencies are on that particular version.
Imagine the scenario where a consumer microservices is deleted, and stops publishing pacts. If you calculated the dependencies at the application level, then this dependency would never go away.
@Armen Chuljyan can you reproduce your issue using this tool please
Indicate what you expect/want to happen, and what actually happens.
m
The dependencies are on that particular version.
If you think about it, it has to be this way. One minute the application has 0 dependencies, and the next minute it has 1. When it has 0 it is always safe to release (as far as Pact is concerned). Once it has a dependency, we then have more information to check (is the dependency relationship satisfied) before we let it through
don’t quite agree, deployment shouldn’t happen due to a failure in the “can-I-deploy” stage
In case I wasn’t clear, I see a pipeline as a serious of stages that must be passed before moving on to the next. If your unit tests fail, usually in a “pipeline” you wouldn’t proceed to the next step (you might, to get additional feedback) but at th every least, the pipeline would still fail because an important check failed. Pact tests should be thought of as (something like) a unit test that checks you can effectively collaborate with other applications. If these tests fail, it should be a clear warning sign that something is wrong.
a
Agree @Matt (pactflow.io / pact-js / pact-go). But imagine you're not using Pact Broker webhooks and running pact validation by running a downstream pipeline based on GitLab dependencies. This means that you can't distinguish between cases where the contract is published unchanged, and there is no need to run a contract validation and your contract check will always run (which is actually not good). And now you want to avoid the consumer contract test failing if the contract validation pipeline fails for a reason unrelated to the contract test. So, for such type of configuration this could be a solution to avoid contract unrelated failures and would make the contract testing flow more stable. Of course assuming that "can-i-deploy" is completely reliable
hi @Beth (pactflow.io/Pact Broker/pact-ruby) What if if we remove pacticopant in this case? I thought we had something like "pact-broker remove-pacticipant" for this purpose, but I think we can remove pacticipant with curl DELETE anyways.
Let me ask another question, in our flow, we would like to allow deployment to test environments in case if the contract test fails using some config flag(we would like to make this configurable for some cases). In this case, we'd like to record the deployed version of the microservice to Pact Broker despite of the contract test failure (so to keep the correct version about the deployed application). Therefore, we need to call "create-or-update-version" to avoid the "record-deployment" command failure. What do you think about it? What pitfalls can we face in this case? Surely excluding this particular deployment, given the obvious fact that we are deploying a microservice that has not passed the contract test.
m
If you know in advance to ignore the failed contract tests, you don’t need a flag on any of the pact CLI commands - you can guard against that in your script that calls it. 
record-deployment
doesn’t care about the result of the contract test, it is stating a fact - 
version X of application Y has been deployed to environment Z
. So you can still call that. I think what will happen eventually is that you’ll get stuck in some loop, where 
can-i-deploy
won’t let you deploy to a certain environment because you’ve brute forced your way around the checks. This will then lead to a serious of guards in your scripts to ignore checks for certain applications under certain conditions, which I think will be a mess to maintain.
a
Thank you Matt, I agree with you that this is not a good practice, but from time to time we have to deal with this. And with regards to deployment recording.. if the pacticipant version does not exist in Pact Broker, then record-deployment for that version fails: 
service-X, version Z not found (error requesting <https://pact-broker>... status=404)
So, to record a consumer version deployment that has not published a pact file, you must call create-or-update-version on that version of the consumer.
👍 1
b
Yes. That is recommend in the docs.
7 Views
Open in Slack
PreviousNext
Powered by