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

@Dominick Campbell has left the channel

Hi Could anyone point me to documentation for recording deployments but with HTTPS? I can only find the CLI commands, but they need to communicate via HTTPS in the end anyways so there must be a way, right? (Out of multiple unreleated reasons, using the pact_broker_cli is a lot more effort compared to a curl call)

Hi, Question about the Pact Broker/publishing to the broker. If you have a contract that has been verified for a particular version (and say you tagged it with some metadata), if you were to re-run that verification again with no tags, would it take away the tags from the published verified version in the broker?

Hi guys 👋 may I ask please what is the purpose of the

--build-url

parameter in the

publish

command? When I use it, where in pactbroker is it used? https://docs.pact.io/pact_broker/client_cli/readme#publish We are using Pact Broker OSS.

Hi, Is it possible to generate an adhoc PACT_URL? So if I wanted to verify a particular contract, can I generate the URL to run the provider verification? Rather than it be generated just when the webhook fires

Only once it's uploaded. The Pact URL should be stable

@Paolo Laurenti has left the channel

Hello, we're currently having with the OSS Pact Broker. Several pipelines report, that there are no pacts to verify, even if there are. The UI of the broker gives conflicting information. When I configure the matrix to show all contract versions on the 'main' branch of the consumer, it shows a several entries. However, when I configure it to only show the latest contracts of the main branch there are no entries at all. Does anyone know how this can be? We do have a script running each night that removes branches from the broker that are no longer existent in the repository, but calling the branch deletion endpoint shouldn't delete any contracts that are still on other branches, right? (I already tried this out with a local broker instance and that doesn't seem to be the case).

Hi Team, I am using this pact broker image : https://github.com/pact-foundation/pact-broker-docker Recently I started getting intermittently 504 error when trying to connect to the broker. [ERROR] ExternalInstanceProviderPactTest.pactVerificationTestTemplate(PactVerificationContext) » RequestFailed Request to path 'pact-broker-url' failed with HTTP response 504. Is there anything I can do to fix this? I have the cleanup cron job already configured. Thanks in advance.

Release - Version 2.117.0 New release published by github-actions[bot] #### Features • add provider pacts by branch endpoints (</pact-foundation/pact_broker/commit/0ccff2ec|0ccff2ec>) • PACT-4511/updated matrix decorator to return app instance for an env if present (#838) (</pact-foundation/pact_broker/commit/8bc24e72|8bc24e72>) • support provider states by branch/env (</pact-foundation/pact_broker/commit/f4db396f|f4db396f>) #### Bug Fixes • update hal relations for provider pacts (</pact-foundation/pact_broker/commit/b6e8e8e3|b6e8e8e3>) • drop pact-support pin (</pact-foundation/pact_broker/commit/3c7eb4c5|3c7eb4c5>) • fixed the text fixtures (#826) (</pact-foundation/pact_broker/commit/28035c27|28035c27>) • test • update expectation of webhook_certificates source format dependant on rb version (</pact-foundation/pact_broker/commit/5364c1b1|5364c1b1>) • deps • add mutex_m/csv/ostruct/pstore (</pact-foundation/pact_broker/commit/075d2522|075d2522>) pact-foundation/pact_broker

Release - Version 2.117.1 New release published by github-actions[bot] #### Bug Fixes • dashboard loading after zeitwerk rename prep (</pact-foundation/pact_broker/commit/13112e2f|13112e2f>) pact-foundation/pact_broker

Hi guys, I would like to ask for some recommendation. We are running Pactbroker in Kubernetes. Currently we are using AWS RDS with these parameters

Instance class: db.t3.medium
vCPU: 2
RAM: 4 GB
Engine version: 13.18

but lately we have been having problems with SQL queries timeouts

Exception: Sequel::DatabaseError: PG::QueryCanceled: ERROR:  canceling statement due to statement timeout

We are preparing to set up DB cleanup, but at the same time we are considering whether we should increase RDS resources. Do you have any experience with what Instance class would be suitable?

Hey there everyone! I have a question on the flow of working with pending pacts. We just ran into a problem, where the pact was verified on a feature branch and the results were published to the broker as part of the pipeline. This causes the provider tests on most other feature branches to fail. The documentation (and from I can tell the code as well), a pact is verified if either a) The contract has been verified on this branch before. b) The contract has been verified on any branch, that existed before this branch. Does this mean, the other feature branches would need to wait for the branch that originally verified the contract to be merged? Or shouldn't a feature branch upload verification results in the first place? For context: • the consumer team hasn't fully finished up setting their pact configuration and so far has only published pacts for their tagged versions (where the providerBranch is also set to the Tag). Their main branch in the Pact Broker is not yet set. • we are using WIP pacts What are we doing wrong?

I have a question about pact-broker interface. Why the pact-broker cli in windows has the command like this:

pact-broker can-i-merge --pacticipant <pacticipant> --version <version>....

while in linux it is like this:

pact-broker can-i-merge --pacticipant=<pacticipant> --version=<version>....

if one is using the same script to call in linux or windows, it has to take into account what base OS it is running. Why not have one unified interface?

Hi team, it looks like the pact-broker was upgraded recently. We had some environments defined and visible in ui Settings section. Now it's empty - was it intended change? When listing envs via CLI I see all of those, but why those disappeared from ui?

Hi folks, can you please take a look? https://github.com/pact-foundation/pact-broker-docker/pull/306 I would like to suggest bumping the base image for the broker from ruby:3.3.10-alpine3.21 to apline3.23, because 3.21 has several vulnerabilities. There's so many versions of ruby images, that idk which to pick, so I picked the one that seemed the closest to the existing one. Is there some testing you'd like to run other than the github actions workflow on the PR?

Hi guys, in past we had to set the default branch for given pacticipant. We used

pact-broker create-or-update-pacticipant --name=pacticipnat --main-branch=main

Now I would like to remove the setting and leave empty to use default according to auto_detect_main_branch and main_branch_candidates But I did not find a way how to remove previously set

Main branch

by cli. Do you know any way please?

Hey there, I want to address the issue again that I addressed here already. The broker currently treats all pacts verified, when they have been verified on any branch, that has been created before the current branch. This may lead to unstable pipelines, because contracts may have been verified on a feature branch, but not yet merged into the default branch. This causes all newly created branches to have failing pipelines and be blocked from merging until the verifying branch is merged. Disabling verification publication on feature branches is not an option, because then can-i-merge fails for the provider. I want to propose again to only consider contracts as verified, if they have been verified on the default branch. This would also fit the usage of 'can-i-merge': > Checks if the specified pacticipant version is compatible with the configured main branch of each of the pacticipants with which it is integrated. In the original thread @Matt (pactflow.io / pact-js / pact-go) wrote that the current behavior might be by design, because the broker can't know wether a branch contains the contract implementations. This proposed would not eradicate the problem but rather make it occur slightly less often, because the base premise is more plausible. Like Matt already wrote, there is no way to calculate wether to include the contracts either way. The only way we can determine if the default branch still supports all contracts is, if we run the provider tests on the default branch, which we do with each commit anyway. I might be able to provide a PR for this, but I haven't had a lot to do with Ruby yet, so I can't guarantee anything.

Hi all. I'm currently investigating Pact to see how it might help my team identify and fix compatibility with rolling / blue - green deployments. Yesterday, I ran a scenario where I deliberately broke compatibility initially in the provider, and then the consumer. The Matrix and

can-i-deploy

tool agreed (correctly) with the initial provided based break, but seem to disagree on the consumer break. I attach images of the Matrix and

can-i-deploy

tool output. I will post further diagnostic info in a thread. Is this expected? I'm, perhaps incorrectly, expecting

can-i-deploy

to say "computer saids no...."

Having spent some playing, reading, and thinking, I'm still struggling to understand a couple of things that I hope someone can provide advice on. Firstly, I wonder whether this guidance about modelling long running deployments holds true with Releases? https://docs.pact.io/implementation_guides/jvm/provider/junit5spring Certainly in our circumstance, and probably most others, I'd argue that there is "an advantage to recording Provider v2 as being in production during the time period of the deployment". Being able to model the versions being rolled off and rolled on provides a convenient way to reference the interesting versions that the

can-i-deploy

tool could work against to answer whether a deployment is safe. Is the key concern here premature assignment of 'deployed' or 'released' before the actual deployment? Perhaps this is a nomenclature issue or your trying to maintain strict definitions of the vocabulary being used? The scenario modelling I've conducted over the past few days suggests that using

record-release

and

record-support-end

alongside a

production

environment does provide the general and backwards compatibility requirements we have during blue / green deployments. Well, issue 903 withstanding. However, even though it works, I'm not keen to follow an "anti-pattern" as the document suggests. Are there specific technical or roadmap reasons why this approach really shouldn't be used? If we do use Pact going forwards, can anyone advise what consumer selectors would be suitable for our "Can I deploy" goal? We use trunk based development and won't necessarily deploy the latest versions at any specific time, and certainly don't deploy every version to production. Perhaps an illustrative matrix could provide an example:

+--------------------------+--------------------------+
| Consumer version         | Provider version         |
+--------------------------+--------------------------+
| 1                        | 1                        |
| 2                        | 2 deployed to prod       |
| 3 deployed to prod       | 3                        |
| 4                        | 4 want to deploy to prod |
| 5 want to deploy to prod | 5                        |
| 6                        |                          |                     |
+--------------------------+--------------------------+

Trunk based means branching selectors won't work. tags are deprecated(?), latest wouldn't work due to consumer@6 and provider@5. From https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors, it does appear that

{ "deployedOrReleased": true }

would be most suitable if not for requiring 'premature release of customer@5 and provider@4. However, in my project's existing nomenclature, these versions would have already been released by Maven... Want I want to obtain is assurance of compatibility between consumer@3, consumer@5, provider@2 and provider@4 to ensure blue/green would work?

Hello there! Pact-Cli docs/help for

describe-version

mention

--environment

, but when I run it the command errors. From what I can tell, this may be a version mismatch or unsupported option in the CLI build I’m using Version is 1.77.0 and I pull lates from docker.

➜  ~ pact-broker describe-version --pacticipant test --broker-base-url=$PACT_BROKER_URL --environment production --deployed

Unknown switches "--environment", "--deployed"

This is a warning rather than an error so as not to break backwards compatibility. To raise an error for unknown options set PACT_BROKER_ERROR_ON_UNKNOWN_OPTION=true

ERROR: "pact-broker describe_version" was called with arguments ["--environment", "production", "--deployed"]

Usage: "pact-broker describe-version -a, --pacticipant=PACTICIPANT -b, --broker-base-url=BROKER_BASE_URL"

Is

describe-version --environment

expected to work in current Pact CLI version?

@Norbert Gulácsi has left the channel

Release - Version 2.119.0 New release published by github-actions[bot] Features • support customising webhook requests (</pact-foundation/pact_broker/commit/d20a8274|d20a8274>) • Optimize WIP Query Performance to Prevent Timeouts on Large Datasets (#902) (</pact-foundation/pact_broker/commit/711ac3c6|711ac3c6>) Bug Fixes • add missing import and small improvement to batch delete (#899) (</pact-foundation/pact_broker/commit/2e83d012|2e83d012>) • new unit test failure (</pact-foundation/pact_broker/commit/6c39e927|6c39e927>) • avoid N+1 cascade (</pact-foundation/pact_broker/commit/681d98d9|681d98d9>) • dont create index for mysql (</pact-foundation/pact_broker/commit/1ec72cc8|1ec72cc8>) • Pacticipant API returning undeployed versions in pacticipant deployed-environments endpoint (#889) (</pact-foundation/pact_broker/commit/e217d3ba|e217d3ba>) • PACT-5504 • use batch delete to speed up deletion (</pact-foundation/pact_broker/commit/e908035a|e908035a>) pact-foundation/pact_broker

Hi, I am trying to integrate datadog APM with the pact broker, as we're dealing with slowness and I'd like some runtime metrics to understand where the slowness is coming from. The issue I am running into is that the pact-broker image is built with alpine which is unsupported for datadog apm. I was wondering if there were plans to support a debian based image. I am trying to avoid forking and rebuilding myself. I was also wondering if you would consider supporting a prometheus scrape with runtime metrics from the puma runtime?

Hi all, any chance a new pact-broker-docker release could be cut to pickup the bumped dependencies ~ https://github.com/pact-foundation/pact-broker-docker/issues/334 ?

Release - Version 2.120.0 New release published by github-actions[bot] Features • expose released environments on branch/tag version list endpoints (#969) (</pact-foundation/pact_broker/commit/bea68a7d|bea68a7d>) • expose released environments on version API (#963) (</pact-foundation/pact_broker/commit/d6f7f17b|d6f7f17b>) • return more webhooks attributes in logs decorator (#961) (</pact-foundation/pact_broker/commit/4e2d1b13|4e2d1b13>) • paginate pacticipants_for_label (</pact-foundation/pact_broker/commit/088ff444|088ff444>) • add limit to stale branch delete (#933) (</pact-foundation/pact_broker/commit/406c20f3|406c20f3>) • change branch sort order, most recently updated first (#929) (</pact-foundation/pact_broker/commit/b5215a39|b5215a39>) • clean • expose branch_deletion_limit on CleanTask (#938) (</pact-foundation/pact_broker/commit/540afa3d|540afa3d>) • add stale branch lifecycle and automated cleanup (#912) (</pact-foundation/pact_broker/commit/1ba6354f|1ba6354f>) • PACT-6253 • add json_schemer as explicit gem dependency (#916) (</pact-foundation/pact_broker/commit/dc8910ce|dc8910ce>) Bug Fixes • spec • rebuild success-after-latestby fixture with distinct provider versions (</pact-foundation/pact_broker/commit/778d25d2|778d25d2>) • rebuild latestby filtering fixtures to genuinely pin the ordering contract (</pact-foundation/pact_broker/commit/9276aa79|9276aa79>) • broken SQL in pacticipants_for_label resource (#944) (</pact-foundation/pact_broker/commit/bf37cdfc|bf37cdfc>) • use cvpv when checking can-i-deploy against an environment (#903) (#934) (</pact-foundation/pact_broker/commit/7163652d|7163652d>) • remove deadcode, improve testing with UTC (#924) (</pact-foundation/pact_broker/commit/76c2407a|76c2407a>) • join with pacticipant when query main branch (#921) (</pact-foundation/pact_broker/commit/3dae89be|3dae89be>) pact-foundation/pact_broker

Hi. So, I'm finally able to try and test the fix for github.com/pact-foundation/pact_broker/issues/903 . It is hopefully fixed in github.com/pact-foundation/pact_broker/…/v2.120.0 . However, the latest docker version available looks to be 2.119 hub.docker.com/r/pactfoundation/pact-broker/tags Is this right, or should there be a 2.120 release available in docker hub?

When I downloaded and re-ran

latest

, the hal browser still reported

x-pact-broker-version: 2.119.0

...