Hi there, does the self hosted broker supports SSO?

Hello, is it correct that the OSS Broker does not fire the

contract_requiring_verification_published

event when no provider has ever verified a contract from this consumer? So if I want to trigger the pipeline for a brand new interface I also need to add the

contract_content_changed

event to the webhook configuration?

I think that’s right. I can’t remember why it doesn’t fire it - probably because it doesn’t have any provider version to say “this version needs to verify the pact”

but I wouldn’t add the second webhook for triggering the provider exactly once

Yeah, that absolutely makes sense. Just realized that those would need to be separate webhooks anyway, because the contract_content_changed doesn't seem to have access to the variables that the other does, which confirms your guess.

> but I wouldn’t add the second webhook for triggering the provider exactly once Oh yeah right, especially because whatever this pipeline runs will likely fail anyway because it's impractical for the provider to setup their contract tests before the consumer did (and published their first contract)

Hm. Strange. The contract was verified (not on the main branch though), pushed a modified version and the webhook still isn't triggered (not failed to trigger, but just not trigged, also reportely like that by broker UI).

Hello. Is there a way to get an error from the broker when a pact or swagger gets published to a non-existent pacticipant?

@Spencer has left the channel

Release - Version 2.113.0 New release published by github-actions[bot] Features • aggregated provider state endpoint (#734) (</pact-foundation/pact_broker/commit/108d11a7|108d11a7>) • add more logging to data migrations (</pact-foundation/pact_broker/commit/9482d44d|9482d44d>) Bug Fixes • make sure last_action_date always returns a DateTime object (</pact-foundation/pact_broker/commit/d60c264e|d60c264e>) pact-foundation/pact_broker

Release - Version 2.113.1 New release published by github-actions[bot] Bug Fixes • Update openapi_first and use it's coverage thing (#783) (</pact-foundation/pact_broker/commit/b3da850b|b3da850b>) • incorrect ProviderStates policy name. (#782) (</pact-foundation/pact_broker/commit/bddfd2d0|bddfd2d0>) pact-foundation/pact_broker

Release - Version 2.113.2 New release published by github-actions[bot] #### Bug Fixes • downcase Content-Type header (</pact-foundation/pact_broker/commit/6eebfbdf|6eebfbdf>) • downcase X-Pact-Broker-Version header (</pact-foundation/pact_broker/commit/8dfb3ac2|8dfb3ac2>) • downcase Cache-Control header (</pact-foundation/pact_broker/commit/6ceae489|6ceae489>) • downcase Vary header (</pact-foundation/pact_broker/commit/a43416a3|a43416a3>) • add webmachine monkey patch to exclude webrick default load (</pact-foundation/pact_broker/commit/ef674d37|ef674d37>) pact-foundation/pact_broker

Release - Version 2.114.0 New release published by github-actions[bot] #### Features • support extended verification results (#778) (</pact-foundation/pact_broker/commit/18f571c8|18f571c8>) pact-foundation/pact_broker

Good afternoon. How do I get the list of released consumer versions from a self-hosted pact broker? I.e. the list of versions marked by

pact-broker record-release

? Also, how do we bulk

record-support-ended

them?

Tags are generally considered deprecated. But are there any plans to delete them? I am building workflow where I promote artifacts (docker images) to specific environments. I use commit id for pact version (as recommended) but I do not have an easy way to get commit id from docker tag (semver). I planned to tag contracts and verifications with semver version and use api to get version from tag and then run can I deploy against it. But if I lose tags in near future it will all fall apart. Is there any reasonable way to do it any other way instead of having external system tracking matching between semver and pact version?

👋 Hello, team! someone can help to clarify how can I publish an example-consumer into pact-broker?

Hi team, I’m looking for some advice on our current Provider's CI/CD setup with Pact Broker. We have two separate branches:

staging

and

production

, which may contain different code as features are tested in staging before being rolled out to production. 1. Would it make sense to maintain separate sets of Pact stages for each branch? 2. I've observed that when a webhook is triggered, the verification always runs against the main branch (staging), regardless of which branch initiated the process. This could potentially cause issues when the branches diverge. Any suggestions on how we can improve this setup or handle branch-specific verification more effectively? Thanks!

Would it make sense to maintain separate sets of Pact stages for each branch?

I’m not sure I entirely follow. The concept of “branches” are there to map changes for a given branch. Are you using

pact-broker record-deployment

when you deploy to each environment?

I’ve observed that when a webhook is triggered, the verification always runs against the main branch (staging), regardless of which branch initiated the process. This could potentially cause issues when the branches diverge.

When a webhook fires, it specifies in the payload which version (and branch/environment) that it needs to check against. Your webhook target should read the value of that body, and checkout the correct code accordingly. See also https://docs.pact.io/pact_broker/webhooks#using-webhooks-with-the-contract_requiring_verification_published-event

Release - Version 2.115.0 New release published by github-actions[bot] #### Features • group provider states by consumers (</pact-foundation/pact_broker/commit/e39860a9|e39860a9>) #### Bug Fixes • dedupe non unique provider states #789 (</pact-foundation/pact_broker/commit/3cf22169|3cf22169>) • explicitly order labels by name (</pact-foundation/pact_broker/commit/d25746c1|d25746c1>) pact-foundation/pact_broker

According to https://docs.pact.io/getting_started/versioning_in_the_pact_broker the commit SHA should be used as version. I understand the reasoning behind that, but what I don't understand how this plays together later with can-i-deploy. When deploying, I do not use a commit SHA, but a real version (e.g. 1.1.10). I would need to know the commit SHA when doing the can-i-deploy. I guess I could look it up from Git, but then need Git access at that moment (which I currently don't have).

According to the Pact Broker documentation, using tags is no longer the recommended approach for managing versions. Instead, branches are preferred. However, the Pact CLI (as shown in the attached) still requires specifying a

--latest

when retrieving the latest published pact version for a consumer/provider, which implies using tags like

--latest <branch_name>

. Given this shift in recommendation, how can I retrieve the latest published pact version for a pacticipant based on the branch name, without relying on tags? Is there a recommended way to achieve this using the Pact Broker CLI?

Hey, is there a way to target a provider branch other than main when running:

pact-broker can-i-deploy

? I'd like to test using a webhook on a separate branch but is recording a deployment in test environment and then targeting that the best approach or can I target a provider branch specifically?

On top of that, is there a way to delete webhooks from the broker? I can't see anything in the CLI docs

Hey folks, in our company we are self-hosting the Pact-Broker and want to put it behind a Cloudflare Zerotrust tunnel and disable the Pact-Broker's own basic auth. This means that we have to send custom headers for authorization (

CF-Access-Client-Id

and

CF-Access-Client-Secret

with the calls to the Pact-Broker. In our pipeline we are using the Pact CLI tool which is only sending basic auth token as far as we understood. Same goes for Pact JVM for our unit tests which are communicating with the Pact-Broker. Do you have any idea how one could solve this issue or is there a feature planned to be able to send custom headers as well?

Hi all, I'm attempting to build in a webhook trigger to a Jenkins multibranch pipeline on the provider. My challenge is that the multibranch-webhook-trigger only wants to build branches with changes, which during provider validation is unlikely the case. Has another faced this challenge, and any tips to resolve? Have spent a few hours down rabbit holes of documentation to no luck thus far. Appreciate any help 🙏

Hi Team, Do we have binaries available for pact-foundation/pact-cli ? I can only see docker image. I have upgraded pact-go from v1 to v2 and looks like we have to use pact-cli now for publishing the pacts. Can anyone please confirm. Appreciate any help. Thanks.

Hey folks, what's the recommended way to deal with monorepos and webhooks? We have a monorepo which hosts services like my-service and other-service. Whenever a webhook triggers, we get the

my-service

as a name, but I don't think there's a way to map it to a git repo - other than using an external datastore or a service, but nothing built into pact-broker. Is that correct, or am I missing some metadata?

Release - Version 2.116.0 New release published by github-actions[bot] #### Features • render sync messages (</pact-foundation/pact_broker/commit/c0ad9f5b|c0ad9f5b>) • render async messages mixed v4 and v3 (</pact-foundation/pact_broker/commit/d727d950|d727d950>) • add deployed-environments to pacticipant response and tag versions (#804) (</pact-foundation/pact_broker/commit/d8c7ee65|d8c7ee65>) • show deployed-environments in branch versions response (#803) (</pact-foundation/pact_broker/commit/cc346010|cc346010>) • add tag_versions endpoint (</pact-foundation/pact_broker/commit/42bf5203|42bf5203>) • added deployed-environments to

/parcticipants/$name/versions

abd (#801) (</pact-foundation/pact_broker/commit/af66f6a3|af66f6a3>) #### Bug Fixes • rubocop errors (</pact-foundation/pact_broker/commit/e311422c|e311422c>) • refactored long consumer_contract method (</pact-foundation/pact_broker/commit/7d8af4d5|7d8af4d5>) • remove unsupported Pact::Term from test example (</pact-foundation/pact_broker/commit/1a4056bd|1a4056bd>) • rename interaction_async.erb filename (</pact-foundation/pact_broker/commit/77ddcb59|77ddcb59>) • refactored the query to filter out duplicate integration rows (#806) (</pact-foundation/pact_broker/commit/7bff0f0d|7bff0f0d>) pact-foundation/pact_broker

Is there a way I can check in the pact broker OSS version, which interaction verification failed for a pacticipant