Feature: Support Provider verification against Pact Broker listening on a port other than 9292

[johnwatson484]

Issue Classification

• [X ] Feature request
• [ ] Bug report

Feature Request

When verifying Pacts against a Pact Broker, there doesn't seem to be any way to change the port the broker is listening on from 9292.

Our Pact Broker is hosted in an Azure Container Instance and has exposed port 9292. In front of that we have a reverse proxy set so our developers on their dev machines can reach the Pact Broker on something like pact-broker.our-domain (if connected to VPN).

When running provider tests locally they fail, debug logs show that connection to 9292 failed. The issue is we need the port to be 80.

Here is a simplified example of the test we have written:

const { MessageProviderPact } = require('@pact-foundation/pact')
const createMessage = require('../../app/messaging/outbox/create-message')

describe('Pact Verification', () => {
  test('validates the expectations of ffc-demo-payment-service', async () => {
    const claim = {
      claimId: 'MINE123',
      propertyType: 'business',
      accessible: false,
      dateOfSubsidence: '2019-07-26T09:54:19.622Z',
      mineType: ['gold']
    }

    const provider = new MessageProviderPact({
      messageProviders: {
        'a request for new payment schedule': () => createMessage(claim).body
      },
      provider: 'ffc-demo-claim-service',
      consumerVersionTags: ['main', 'dev', 'test', 'preprod', 'prod'],
      pactBrokerUrl: 'https://pact-broker.our-domain',
      pactBrokerUsername: 'ourUsername',
      pactBrokerPassword: 'ourPassword',
      verbose: true,
      logLevel: 'DEBUG',
      port: 80 // can't do this as no option to change port
    }) 
    return provider.verify()
  })
})

The above test works fine if we run it against a local Pact file but not when we try to use the URL. It also doesn't work if we suffix the pactBrokerUrl with the port like so: https://pact-broker.our-domain:80 and there doesn't seem to be a port property we can pass to MessageProviderPact.

So as a feature request, I'd like to suggest that there is flexibility to specify a different port, other than 9292 for those with a similar use case as ours.

Also if there is a work around or any advice that can be shared to unblock us now that would also be appreciated.

[mefellows]

We absolutely support the broker being on another port, so I suspect there is either a bug or a configuration issue somewhere.

Can you please set logs to debug level and share them so we can see what's happening?

See also https://docs.pact.io/pact_broker/configuration/#running-the-broker-behind-a-reverse-proxy. You may need to configure the correct headers on your load balancer to ensure the Pact Broker knows what port/scheme etc. it is on.

You can see if it's correct by issuing a curl or something to the root of your broker, it will have links in the response. If those links have port 9292 in it, it means your broker is not configured correctly.

[bethesque]

You haven't said which Pact Broker Docker image you're using, but I'm guessing it's the pactfoundation/pact-broker one if it is running on port 9292. You can configure the port that it runs on here https://docs.pact.io/pact_broker/docker_images/pactfoundation#other-environment-variables but as the image will not run with super user permissions, it won't bind on a port under 1024. You'd need to run a reverse proxy in front of it to expose port 80 as Matt has said above.

The correct way to specify a custom port is pactBrokerUrl: 'https://pact-broker.our-domain:XX'. It would be strange to run HTTPS over port 80 though - it's usually on port 443.

[johnwatson484]

@mefellows @bethesque thanks both for your help.

Apologies, I did mean to say port 443 and not 80.

We've been able to solve this by updating our load balancer in line with the documentation shared by @mefellows. We can now successfully verify the contracts from our local machines against the broker.

No new feature required and no issue so I'll close this request.

Thanks again.

[mefellows]

Great to hear, thanks for confirming @johnwatson484.