are you saying there is a cyclical dependency (i.e. there are two contracts A -> B and B -> A)?

Trying to deploy on Service A (provisioning-service) :

Computer says no ¯_(ツ)_/¯
CONSUMER             | C.VERSION | PROVIDER        | P.VERSION | SUCCESS? | RESULT#
---------------------|-----------|-----------------|-----------|----------|--------
provisioning-service | 1.0.126   | devices-gateway | ???       | ???      |

Trying to deploy service B (devices-gateway):

Computer says no ¯_(ツ)_/¯
CONSUMER        | C.VERSION | PROVIDER             | P.VERSION | SUCCESS? | RESULT#
----------------|-----------|----------------------|-----------|----------|--------
devices-gateway | 1.0.90    | provisioning-service | ???       | ???      |        
There is no verified pact between version 1.0.90 of devices-gateway and the version of provisioning-service currently deployed to staging (no such version exists)

temporary, to allow me to deploy on my new environment (staging), I set the can-i-deploy to dry-run in my pipeline and manually made the deployment after that...

@Matt (pactflow.io / pact-js / pact-go) We have an event driven architecture where service are highly decoupled, I’m not sure I should use contract for events in my case… or I’m doing something wrong?

The can-i-deploy tool supports bi-directional dependencies between applications, however, as you are introducing pact into an existing relationship where there are already versions deployed, you will need to disable can-i-deploy to get the first pair of contracts out into production. Make sure both sides are actually passing before you do this. Or, you can choose one direction to start with (deleting the pacts for the other direction if you have already published them), get that deployed, then add in the pacts for the other direction. Thereafter, you will need to ensure you only ever make changes in one direction of the relationship at a time, otherwise can-i-deploy will very correctly stop you from deploying. If you have changes in both directions that each depend on the other, you will be in the situation where you must deploy both applications at the same time, at which stage you would probably be better off if both services were part of a single application. Bi-directional dependencies tend to cause a lot of issues in both testing and deployments!