Another question on verifying; when the broker triggers (via a webhook) a verification build by passing an

pactbroker.consumerName

and

pactbroker.pactUrl

, I assumed I would need to set the following verify options when calling

new Verifier(opts).verifyProvider()

•

pactUrls

set to an array containing the a single string with value set from

pactbroker.pactUrl

•

consumerVersionSelectors

set to an array containing a single `consumer`selector with value set from

pactbroker.consumerName

for example:

{
  "pactBrokerUrl": "https://...",
  "provider": "foo",
  "providerBaseUrl": "<http://localhost:55020>",
  "logLevel": "info",
  "providerVersionTags": [],
  "consumerVersionSelectors": [
    {
      "consumer": "bar"  <<-- value set from pactbroker.consumerName
    }
  ],
  "pactUrls": [
    "<full url to pact as passed via pactbroker.pactUrl>"
  ]
}

When I run this, the test retrieves the specific pact via that URL, and runs the given tests successfully. But it then fails with:

2024-08-01T10:48:00.164788Z ERROR ThreadId(12) pact_verifier: Failed to load pact - No pacts found for provider 'foo' matching the given consumer version selectors in pact broker 'https://...': failed validation - ["consumerVersionSelectors: must specify a value for environment or tag or branch, or specify mainBranch=true, matchingBranch=true, latest=true, deployed=true, released=true or deployedOrReleased=true (at index 0)"]

That seems odd, because I don't know what the environment/tag/branch is (and surely that's all wrapped up in the pact on the other end of the URL?). If I omit the consumer version selectors altogether, then it seems to verify all pacts from all consumers. What's the correct way to specify that I just want to verify the pact with a given URL?

just pass pactUrls, the consumer/provider name is retrieved from the pact https://github.com/pactflow/example-provider/blob/master/src/product/product.consumerChange.pact.test.js consumer version selectors are only used for provider based changes

I did try that, with opts:

{   
  "pactBrokerUrl": "...",   
  "provider": "foo",   
  "providerBaseUrl": "...",   
  "logLevel": "info",   
  "providerVersionTags": [],   
  "pactUrls": [     <pactUrl>   ] 
}

but that resulted in not only verifying the pact with the specific URL, but also all pacts from all consumers.

can you try removing the

"provider"

option? I have a feeling that it is being passed to a consumer version selector call to the broker, and fetching latest for each associated consumer for the provider

I'll give that a go and report back shortly...

Thanks for the feedback. This has been raised a few times, as it catches a lot of users out. Some similar tickets. Pact-JVM is its own impl, Pact-JS along with many other impls use the pact-reference core now (built in rust), so that would be a better place for a change to go https://github.com/pact-foundation/pact-reference/issues/250 https://github.com/pact-foundation/roadmap/issues/47

• The online docs might benefit from being more specific about how to handle the pactUrl case (i.e. that you *must not specify pactBrokerUrl, consumerVersionSelectors provider when you do this)

yep deffo think we can be more explicit. Have you seen this page? https://docs.pact.io/provider/recommended_configuration#verification-triggered-by-a-contract-requiring-verification-published

When the pact URL is known, the

pactBrokerUrl

,

providerName

,

consumerVersionSelectors/consumerVersionTags

,

enablePending

,

includeWipPactsSince

fields should not be set. You can see an example of switching between the two verification modes (all vs changed) in this Node example

Having us detect that in code and informing the user would be a better DX experience for sure

Thanks - I hadn't seen (or had but not remembered) that page, but that is useful. I think having the validation code detect those illegal combinations and reporting on them specifically would be great. I understand why its so, but this kind of information is spread in the docs amongst different areas (provider, pact-js, pact-jvm) so it can be a little tricky to pull all of the threads together.