I have two services utilizing pactflow currently. ...
# pactflow
a
I have two services utilizing pactflow currently. Both are updating versions for a contract change:
Copy code
Computer says no ¯\_(ツ)_/¯

CONSUMER   | C.VERSION | PROVIDER        | P.VERSION | SUCCESS? | RESULT#
-----------|-----------|-----------------|-----------|----------|--------
hl-console | 1.6.7     | hiddenlayer-sor | 1.0.1     | false    | 1      

VERIFICATION RESULTS
--------------------
1. <https://hiddenlayer.pactflow.io/contracts/bi-directional/provider/hiddenlayer-sor/version/1.0.1/consumer/hl-console/version/1.6.7/cross-contract-verification-results> (failure)

The cross contract comparison between the pact for version 1.6.7 of hl-console and the oas for the version of hiddenlayer-sor currently in stage (1.0.1) failed
Copy code
Computer says no ¯\_(ツ)_/¯

CONSUMER   | C.VERSION | PROVIDER        | P.VERSION | SUCCESS? | RESULT#
-----------|-----------|-----------------|-----------|----------|--------
hl-console | 1.6.6     | hiddenlayer-sor | 1.0.2     | false    | 1

VERIFICATION RESULTS
--------------------
1. <https://hiddenlayer.pactflow.io/contracts/bi-directional/provider/hiddenlayer-sor/version/1.0.2/consumer/hl-console/version/1.6.6/cross-contract-verification-results> (failure)

The cross contract comparison between the pact for the version of hl-console currently in stage (1.6.6) and the oas for version 1.0.2 of hiddenlayer-sor failed
I'm trying to wire up my pipelines so on merge of PR it auto deploys but neither of them say they can deploy. Even though both versions 1.6.7 and 1.0.2 work together. Am I misunderstanding how to use can-i-deploy with CD or am I doing it wrong?
Screenshot 2024-07-03 at 12.53.52 PM.png
y
Are you at a point where 1.0.1 Provider and 1.6.6 Consumer are compat and deployed, and you are trying to put through a breaking change, so you really need a big bang deployment or change window to get both 1.0.2 and 1.6.7 into stage?
can the provider support 1.6.6 and 1.6.7 of the consumer, allowing it to deploy, the consumer can then deploy 1.6.7, and remove its reliance on whatever was in 1.0.1
remember can-i-deploy is just a guide, its informing you that there will be a breaking change here so that needs co-ordination between your teams. having a way to break glass c-i-d results is useful for this reason
a
makes sense, seems like my easiest course of action is to delete the old contracts
and in the future we can work towards provider support of previous versions
y
There is a dry-run flag on the can-i-deploy tool, which can be enabled via env var which is useful in these situations of deadlock.
Copy code
[--dry-run], [--no-dry-run]
              # When dry-run is enabled, always exit process with a success
                code. Can also be enabled by setting the environment variable
                PACT_BROKER_CAN_I_DEPLOY_DRY_RUN=true. This mode is useful when
                setting up your CI/CD pipeline for the first time, or in a
                'break glass' situation where you need to knowingly deploy what
                Pact considers a breaking change. For the second scenario, it
                is recommended to use the environment variable and just set it
                for the build required to deploy that particular version, so
                you don't accidentally leave the dry run mode enabled.
makes sense, seems like my easiest course of action is to delete the old contracts
Yeah that is certainly one approach. Hopefully you've been surfaced enough information to move forward but that would be my reading of those results, but it looks like you are using c-i-d tool correctly. Tiny piece of advice, always useful to share the can-i-deploy flags you've used as well as the output (👏 ) thanks for thank, as it's extra helpful for diagnosis!
I'd alway try and have a commit hash as part of your version number too, especially on the consumer side so you can be certain which point in time on a version they relate to, but without knowing more about your setup, your versions numbers might make perfect sense. but there is no harm is augmenting with a commit hash, as if you don't have random data in the consumer contract, pact is able to de-dupe verification results.