https://pact.io logo
Join Slack
Powered by
Hi team, I have a question about `can-i-deploy` to...
# general
t
Hi team, I have a question about 
can-i-deploy
tool. I have the following situation: Provider (P) has long and slow pipeline, consumer (C) has small and quick pipeline. P1 deployed to staging. C1 deployed to staging too. Pact between C1 and P1 was verified successfully. Provider pushed some changes to the 
main
branch with v2 and the pipeline is running. Meanwhile, consumer pushed changes too (pact wasn’t changed) and triggers verification on the provider side against the provider’s 
main
branch with v2, in the end verification passed. Consumer is ready to deploy (provider’s pipeline with v2 still running), however 
can-i-deploy
tool fails, because it can’t find verification record between P1 and C2. P1 is the latest deployed version of our provider on staging. Should 
can-i-deploy
fail in the case when pact wasn’t changed and provider v2 hasn’t beed deployed yet?
According to this doc can-i-deploy should pass since the pact didn’t change and the previous verification was ok
Copy code
This happens when two or more application versions publish the same Pact contract. Duplicate detection is done by hashing the pact file. Note that application versions publishing the same pact contract don't need to be consecutive.

Allowing multiple consumer versions to point to one pact contract file has the major advantage that verifications don't need to be repeated when contracts haven't changed. In the diagram above, a provider that has been verified against consumer version 0.0.0 is automatically considered to have been verified against consumer version 0.0.1. This is particularly useful when working on feature branches.
m
triggers verification on the provider side against the provider’s 
main
branch with v2, in the end verification passed.
why did it trigger a verification? If you’re using the the ‘contract requiring verification published’ event then it wouldn’t trigger if it didn’t require verification. This implies it would. It’s worth checking to see if there are any changes between the versions in your consumer contract. This can occasionally happen if you use dynamic matchers without specifying examples (the framework will insert random values in that case) which will invalidate the pre-verification status
t
why did it trigger a verification?
I don’t use pact webhooks. I trigger provider verification every time when merge request is opened or changes pushed to the 
main
branch in a consumer, and I trigger it as a downstream pipeline. I am thinking maybe I should trigger it only when changes introduced in pacts 🤔
It’s worth checking to see if there are any changes between the versions in your consumer contract. This can occasionally happen if you use dynamic matchers without specifying examples (the framework will insert random values in that case) which will invalidate the pre-verification status
If there is no changes between contracts, should 
can-i-deploy
fail in my case? (I’m sure there are no changes, but I’ll double check)
m
I am thinking maybe I should trigger it only when changes introduced in pacts
ah - you should use webhooks if you can! They are clever enough to do it for you 🙂
If there is no changes between contracts, should 
can-i-deploy
fail in my case? (I’m sure there are no changes, but I’ll double check)
without knowing the flags you are giving to the CLI it’s hard to say, but in general if a contract hasn’t changed between consumer versions for the same provider version then it should be pre-verified and not fail.
t
if a contract hasn’t changed between consumer versions for the same provider version
I use commit sha as a version for both consumer and provider. I have C1 and P1 verified and deployed. Then I have C2 and P1 where contract is the same as between C1 and P1, so contract should be pre-verified and can-i-deploy should pass, is it correct?
I have the following flags: can-i-deploy:
Copy code
script:
    - >-
      pact-broker can-i-deploy
      --pacticipant="my-service"
      --version="$CI_COMMIT_SHA"
      --to-environment="$ENVIRONMENT"
      --broker-base-url="$PACT_FLOW_BASE_URL"
      --broker-token="$PACT_FLOW_KEY"
      --verbose
verification:
Copy code
script:
    - >-
      pact-verifier
      --hostname="app"
      --broker-url="$PACT_FLOW_BASE_URL"
      --token="$PACT_FLOW_KEY"
      --loglevel="info"
      --provider-branch="$CI_COMMIT_REF_SLUG"
      --provider-version="$CI_COMMIT_SHA"
      --provider-tags="$CI_COMMIT_REF_NAME"
      --provider-name="dummy-microservice-provider"
      --filter-consumer="$CONSUMER_NAME"
      --publish
m
I’d take a look at this article: https://docs.pact.io/pact_broker/advanced_topics/see_changes_pact#most-recent-change See if you can find the difference between the two pacts
👀 1
t
Does this article apply for PactFlow? And there is no 
pb:diff-previous-distinct
endpoint in the HAL browser for me, maybe something changed?
m
it should (it’s a superset of the Pact Broker)
t
Wow! 🤩 Thank you very much for the video! Yes, it was helpful! And it returned a lot of changes for my contract 😵‍💫 I am super surprised. But it’s good point for investigations!
🙌 1
m
awesome, glad it helped 🙂
Open in Slack
PreviousNext
Powered by