https://pact.io logo
Join Slack
Powered by
Hello :wave: I have a general question about provi...
# general
b
Hello 👋 I have a general question about provider verification strategy... We have the case just now where one provider has many consumers and they consumers pacts are a mixture of REST and Message. As such we have had to split our 
pact_helpers
(Ruby) to deal with both cases - this has been handled by tagging the consumer pacts as either 
REST
or 
message
. The problem arises in the provider pipeline when we set our consumer_version_selectors: we only want to verify the latest from the main branch of the consumers, but we want to combine this criteria with the existing tag implementation that we have for splitting 
REST
and 
Message
verification. I'm guessing that our implementation of the 
REST
and 
Message
split is not the recommended way, so I'm wondering what is the preferred strategy for this case?
y
Hey Ben So as these are ruby codebases, I assume the rest pacts are v2.0.0 and the message pacts are 3.0.0 and you don’t have pacts that contain both message and http based interactions? This was definitely a limitation in the spec when V3 was introduced, and resolved in V4, but living in a ruby land, we are still a way off getting access to all the V3/V4 goodness from the rust core. The current guidance I’ve seen for those using V3 message pacts, and having consumers with a mixture of message/http pacts, is to name the message consumer / providers differently. This can make the intent a bit clearer from the consumer side, and hopefully the handling on the provider side easier, as the message handling side for verifications with deal with providers with for 
-message
appended onto their name. In that case, the consumer is probably okay to have the same name, for whether they are http or message based, but would just signify message based by changing the provider name
b
Hi Yousaf, your assumptions are correct! I understand the solution you have put forward, it appears better and more maintainable than our current solution and will also solve the issue that we a facing at the moment. We will try to implement this 🙂 Thanks!
🎉 1
Hi Yousaf, we finally got round to implementing this and we're having some trouble combining the two cases in our provider - our code looks like the below. It seems the message and REST setup are interfering with each other. If we put the message block at the top (as shown) then the REST pacts are verified correctly but no the message - and vice versa. Is there some kind of refactor/abstraction that is required to get them to play nice? I'm wondering if our use of 
require "pact/provider/rspec"
is playing a role here also...
Copy code
Pact.message_provider "<provider>-message" do
    honours_pacts_from_pact_broker do
      pact_broker_base_url pact_base_url, {token: token}
      consumer_version_selectors [{mainBranch: true, latest: true}]
    end
  end

  app_version provider_version
  app_version_tags [provider_branch]
  app_version_branch provider_branch
  publish_verification_results publish_flag

  builder do |message_description|
    CONFIG[message_description].call
  end
end

Pact.service_provider "<provider>-REST" do
    honours_pacts_from_pact_broker do
      pact_broker_base_url pact_base_url, {token: token}
      consumer_version_selectors [{mainBranch: true, latest: true}]
    end
  end

  app_version provider_version
  app_version_tags [provider_branch]
  app_version_branch provider_branch
  publish_verification_results publish_flag
end
Open in Slack
PreviousNext
Powered by